IRCloggy #git 2007-01-17

Provider of IRC logs since 2005.

WARNING: As Freenode became unjoinable and lost all warnings in topics, we cannot log channels on Freenode anymore.

	2007-01-17
	→ kazzmir joined	00:03
mugwump	packs should be treated like data partitions imho	00:12
	eg, you might choose to partition by object type, and then sub-partition blobs by sha1	00:14
	with repo-config	00:14
	just like you'd partition a huge time series database table into date chunks	00:15
	dwmw2_gone → dwmw2_SYD	00:15
clee	pco-dhcp205# time git-rev-list --bisect HEAD ^$FIRST	00:46
	9f9af8439be5b16b073d3be0f4ef8b114c578456	00:46
	git-rev-list --bisect HEAD ^$FIRST 15708.67s user 7.39s system 98% cpu 4:25:52.16 total	00:46
	it only took four and a half hours!	00:47
corecode	heh	01:01
	O^3 somebody said	01:01
clee	O(n^3), yes	01:01
	which is ... pretty bad.	01:02
DrNick	it could be worse	01:10
mugwump	but that only affects 'git-bisect next', yeah	02:43
	?	02:43
	you can still use 'git-bisect good' etc to get "close", I'd guess	02:43
	dwmw2_SYD → dwmw2_gone	02:51
	dwmw2_gone → dwmw2_lca	03:13
	→ spearce joined	03:20
clee	spearce: :)	03:41
spearce	evening.	03:42
clee	spearce: almost done with the repack of the second half!	03:42
	spearce catches up on #git logs	03:42
clee	spearce: did you get the mail I sent?	03:42
	dwmw2_lca → dwmw2_gone	03:42
spearce	mail, no, i finished my inbox. nothing from you.	03:42
clee	?	03:43
	weird.	03:43
	I sent it to [email@hidden.address]	03:43
spearce	hehe, your first half was 973 MB. nice.	03:43
	spearce looks in the spam dumping ground...	03:43
clee	it's in my Sent folder. :)	03:44
	Subject: Some more numbers from the svn conversion	03:44
spearce	heh. lets see...	03:45
	btw i don't have repack automatically splitting large inputs. i had to go make a living. :)	03:45
clee	aw.	03:45
spearce	day job doesn't let me connect to #git. or anything else for that matter... damn gov't contracts and security rules.	03:46
corecode	.oO( https/ssh gateway )	03:48
spearce	yea, slow as dirt	03:48
corecode	well, irc just keeps you from working	03:48
spearce	which keeps me from getting the job done, which keeps them from paying me, which keeps me from paying my local utility company for my electric bill.. which keeps me from running my computers that i work on gfi on. funny circle, ain't it? :)	03:49
	clee: i'm not seeing your message anywhere.	03:49
clee	spearce: weirdness.	03:50
	spearce: how about now?	03:50
	clee just bounced it to you again	03:50
spearce	not like it hasn't happened before to me; every once in a while i do wind up with a message lost.	03:50
clee	aw.	03:51
corecode	upstream filterage	03:52
spearce	yea, i think there's some sort of sender verification filter thing that's rejecting some email into my domain.	03:53
	dwmw2_gone → dwmw2_lca	03:57
spearce	dang, 4.5 hours for a bisection? whoa. but given that its O(N^3)... well, that's just to be expected.	03:58
	44MiB index makes sense for 1,898,116 objects.	03:59
	clee nods.	03:59
clee	Writing 2213941 objects.	03:59
	27% (611482/2213941) done	03:59
	:)	03:59
	(rest of pack)	03:59
corecode	spearce: i think any approach "fixing" the compression of gfi's packs is unsuited	03:59
	repack will always perform better	03:59
clee	well, technically, git-pack-objects will always perform better. :)	04:00
spearce	that's always been the plan with gfi. get "good enough" that pack-objects has something reasonable to work from.	04:00
corecode	where is the difference between repack and pack-objects?	04:00
spearce	with Mozilla we had much better deltas due to the way the frontend fed the data, here both of your tools are feeding the data out of order to gfi, which makes pack-objects work harder.	04:00
clee	repack figures out the parameters to hand to pack-objects	04:01
spearce	repack is a tiny shell script that wraps the real tool, pack-objects.	04:01
clee	yay porcelain :)	04:01
corecode	so, how can you help pack-objects?	04:02
	not sure if i understand correctly	04:02
spearce	using relatively short delta chains and keeping the blob data located in the same section of the file makes the IO easier as there's less seeking around.	04:03
	and less CPU work to recover a full revision to recompute the deltas.	04:03
corecode	ah	04:03
	you think that this is an issue?	04:04
spearce	other than that, there isn't much you can do to help it, except to purchase a faster cpu. :)	04:04
	doesn't appear to be, clee packed the first half of KDE in about 2 hours on his system.	04:04
corecode	so, why then even bother?	04:04
spearce	right	04:04
corecode	:)	04:05
	uh uh	04:06
	the git code is really 64 bit clean?	04:06
clee	most of it.	04:06
spearce	should be. a number of folks run it on 64 bit systems.	04:06
	spearce mutters something about broken patches from people.	04:07
	→ segher joined	04:07
corecode	OOH.	04:07
	this is SO ugly	04:08
	global variables galore	04:08
clee	yeah.	04:08
spearce	gfi?	04:08
corecode	no	04:08
	index-pack.c	04:08
spearce	most of git is that way. :)	04:08
	corecode clones latest git and checks again	04:08
corecode	so it seems there are amateur programmers working?	04:09
	uh	04:09
	how ugly	04:09
	corecode shivers	04:09
spearce	most of index pack was Nico and Junio.	04:10
corecode	serious, who does these things	04:10
spearce	what are doing wandering around in that ugly mess?	04:10
corecode	my git code does something like	04:10
	hdr = (struct pack_header *)pack_base;	04:10
	and pack_header contains non-fixed integers	04:11
	like	04:11
	unsigned int	04:11
	how is that supposed to be platform-independant?	04:11
	or is it not?	04:11
spearce	run git-blame on the struct definition and see how's fault it is. :)	04:11
	its supposed to be. it has to be. that's the first 12 bytes of the pack file...	04:11
corecode	i could understand that then	04:11
	well, you know, there are supposed to be systems where sizeof(int) > 4	04:12
	corecode waits for the clone	04:12
corecode	kernel.org, come on!	04:12
spearce	a lot of git code will fall over if that isn't true. I've alawys hated 'int', 'long', etc. in C. Gimme uint32_t, int32_t anyday as I know exactly what its storage is.	04:12
corecode	well, int is really okay if you do a loop	04:13
	but not for storage	04:13
	big no no	04:13
spearce	yes. but i didn't start the mess, i just keep it going as-is.	04:14
corecode	uh.	04:14
spearce	iow i'm guilty of some of that crap too. :)	04:14
	spearce waits for eclipse to finish paging in from swap... sigh	04:14
corecode	needs to be changed	04:14
	this looks like code from the 80ies	04:14
spearce	part of it is Linus' fault I think; he's not a portable userspace programmer. he does kernel on gcc... and that's it...	04:15
corecode	i don't get why the code wasn't created as a library	04:16
spearce	it grew up as a series of tiny one *.c programs meant to run from the command line.	04:16
	over time some functions started to be common between tools, so they started to link against some common objects.	04:17
corecode	yah, but there seems to be a lot of duplication necessary	04:17
clee	the code is a mess.	04:17
spearce	nobody bothered to think about "hey, how do we reuse these global structures" etc.	04:17
clee	people are working on it.	04:17
	git was evolved, not designed. :)	04:17
corecode	i just lost a big share of trust in the code	04:19
spearce	that quickly?	04:19
corecode	what is up with those hand-rolled getopt loops?	04:19
	well, i read some code	04:19
clee	corecode: aren't you a FreeBSD guy?	04:19
corecode	clee: dragonfly	04:19
clee	corecode: what made you think that Linus had started writing trustworthy code all of a sudden? :)	04:20
corecode	but that's related	04:20
spearce	yea our command line option handling is very, very crappy.	04:20
corecode	clee: well	04:20
	so, is this being fixed?	04:20
	i mean, it's just grunt work	04:20
	not really intelectually challenging	04:20
pasky	which is why it is in TODO list so long :)	04:21
spearce	pasky!	04:21
	pasky: dude, what broke on repo.or.cz that my fastimport git fork is totally hosed?	04:21
	corecode: we've talked about rewriting the option handling code. and cleaning up some of the code to be more of a library. resources have instead gone into feature development and bug fixes.	04:22
pasky	broke, hosed?	04:22
spearce	fatal: packfile ./objects/pack/pack-023d4ee9bd06ae3a978eb185894173e60b930ed9.pack cannot be opened	04:22
corecode	you know, i'd clean up parts of it if there was a chance of success getting stuff in without having to read 1000+1 mails about stuff	04:23
spearce	that's during a push.	04:23
corecode	fixes good	04:23
	features not	04:23
spearce	corecode: Junio accepts well written patches, pretty much anytime.	04:23
pasky	-r--rw-r-- 1 repo 65550 161360 2007-01-14 07:23 pack-023d4ee9bd06ae3a978eb185894173e60b930ed9.idx	04:23
	-rw--w---- 1 repo 65550 3008901 2007-01-14 07:23 pack-023d4ee9bd06ae3a978eb185894173e60b930ed9.pack	04:23
	hmmm	04:23
corecode	haha	04:23
	pasky scratches his head	04:23
corecode	funny permissions you got	04:23
spearce	yea, what happened there?	04:24
	corecode suggests adding some bits here and there	04:24
spearce	i pushed like 6000 objects (my fork was waaaaaay behind, and i just pushed something really current) and that happened.	04:24
corecode	aren't the repos -s?	04:24
	or will the objects be pushed nevertheless?	04:25
pasky	hm	04:25
	I have no idea	04:25
	this happened twice before, compeltely randomly, for completely unknown reason	04:25
	works the rest of the time	04:25
	corecode subscribes to git-devel	04:25
spearce	if the repo has git.git as an alternate and we're unpacking to loose objects we won't unpack if the alternate also has the object.	04:26
	but if we're keeping the pack as a full pack (due to a large push) we won't skip the duplicate objects that are already in the alternate.	04:26
	the best way to make that work is to symlink the alternate's refs directory into the fork's refs directory, so the refs are visible to the client during the push. then it can avoid even transmitting the objects the alternate has.	04:27
corecode	so what determines if you're unpacking or not?	04:27
pasky	you shouldn't push the alternated objects in the first place	04:27
	yep	04:27
	that's my long-time TODO ite	04:27
	m	04:27
	but anything git-related is long-time for me now :(	04:27
spearce	corecode: its a configuration limit on the receiving (server) side. default used to be 5000 objects, we dropped it to 100 recently.	04:27
pasky	well still hope it'll change soon	04:27
	anyway I've fixed it for now	04:27
	just drop me a mail if it occurs again	04:27
	I'll try to look at it later	04:27
	why it happens	04:27
	see you	04:27
spearce	ah, that push worked. thanks pasky.	04:27
clee	later, pasky :)	04:27
corecode	that with the symlink i didn't understand	04:28
spearce	corecode: when the client is trying to compute the list of objects to send to the server it grabs the set of commits in the refs directory on the server. These are the things the server has access to.	04:29
	If the server has an object, there's no need to send it again, right?	04:30
clee	so, hm.	04:30
	what about SHA1 collisions?	04:30
corecode	spearce: yah	04:31
	haha, i thought about that as well	04:31
	when you have a collision, you're hosed	04:31
	period.	04:31
spearce	The alternates directory (clone -s) gives the repository a whole slew of objects. But not all of those objects are linked in the refs of the repository.	04:31
	So the client won't know the server has them when it pushes. But if you symlink in the refs then the client can see them, and compute a smaller set to transmit.	04:31
corecode	okay, i have to investigate this refs thing	04:31
	i thought that this is simply a file with a sha1 in it	04:32
spearce	Fleshreaper: SHA1 collisions, yea, you're hosed. you shouldn't get one. if you do the suggested approach is to edit whitespace. :)	04:32
	dammit bitchx again.	04:32
corecode	haha	04:32
spearce	a ref is just a sha1, yes.	04:32
corecode	so why would you have to symlink it?	04:32
spearce	its also saying "i want/have this sha1 here, and anything in its history".	04:32
corecode	ah	04:33
	i see	04:33
	so on the server you get the ref, build the DAG, strip duplicates	04:33
spearce	so if i have two repositories: Central, Dev. and Dev was made by `git clone -s Central Dev` then Dev can see any object in Central, but it has its own private ref space.	04:33
corecode	and transfer the rest	04:33
pasky	clee: there can't be any sha1 collisions :)	04:33
spearce	when I push to Dev from my own local clone of Central I already have a lot of data that Dev can just get from Central, but Dev doesn't know it.	04:34
corecode	no, nuklear powerplants are secure.	04:34
	spearce: well uhm	04:34
	spearce: wait a sec	04:34
	spearce: when working directly with Dev, you'll have access to the data	04:34
	spearce: or not?	04:35
	dwmw2_lca → dwmw2_gone	04:35
spearce	corecode: correct.	04:35
	but what happens when I then want to do: `git clone Central Me; cd Me; hack-hack-hack; git push Dev` ?	04:36
corecode	well	04:36
spearce	I want to send stuff from Me to Dev. But maybe Central already has some of the data I'm trying to send to Dev, so I don't actually need to send it.	04:36
corecode	git is incomplete	04:36
	if git can actually see the data	04:37
spearce	s/incomplete/too flexible/	04:37
corecode	it should use it	04:37
	if there is an alternates link, use it.	04:37
spearce	the problem is we don't know what tips of the DAG exist. its not cheap to compute with a refs directory.	04:37
corecode	how do i list the refs?	04:37
spearce	and the part of the code that is doing the data sharing is logically a layer below the DAG pointers.	04:38
	git-ls-remote url; git-for-each-ref (local only).	04:38
corecode	ah	04:38
spearce	i'll agree with you that this is likely a bug. if we setup an alternate ODB we also should setup the refs so they are visible for better pushing behavior.	04:39
corecode	now i slowly get it	04:39
	the refs are created on clone	04:39
	well	04:40
	follow objects/info/alternates	04:40
	and merge the list of heads	04:41
spearce	that, or setup refs/origin as a symlink to the same location as objects/info/alternates was pointing at during clone.	04:44
corecode	oh, what's branches vs refs/heads?	04:45
spearce	two different words, same meaning. :-)	04:45
corecode	...	04:45
spearce	tomato tomato.	04:45
	hmm, that doesn't come out so good on ICR. :)	04:45
	corecode gets confused	04:46
clee	to-may-to, to-mah-to	04:46
	except I've never heard anyone say to-mah-to	04:46
	corecode prods clee	04:46
corecode	try the cvs repo	04:46
clee	corecode: I am!	04:46
corecode	you are?	04:46
clee	nobody has gotten me a copy of it yet	04:46
	I have a guy in Chicago who used to run a KDE anoncvs mirror	04:46
	and he's burning them to DVDR for me	04:46
	but they won't get here until next week most likely	04:46
corecode	wut? there is no archive at kde.org?	04:47
clee	nope.	04:47
corecode	well, duh.	04:47
spearce	probably ran out of disk when they moved to SVN and it went to 8x its original size. :)	04:47
clee	and all of the old cvs.kde.org, anoncvs.kde.org, etc servers were disabled.	04:47
	pco-dhcp205# (echo HEAD; echo ^$MIDDLE) \| git-pack-objects --delta-base-offset --revs --no-reuse-delta --window=100 .git/second_half	04:47
	Generating pack...	04:47
	Done counting 2213941 objects.	04:48
	Deltifying 2213941 objects.	04:48
	100% (2213941/2213941) done	04:48
	Writing 2213941 objects.	04:48
	100% (2213941/2213941) done	04:48
corecode	that's not real time	04:48
clee	40ecd8feb0950d04aeeae8cce61e1c60b311007e	04:48
corecode	i'd say	04:48
clee	Total 2213941 (delta 1796387), reused 285085 (delta 0)	04:48
	only took ... hours.	04:48
	-rw-r--r-- 1 root root 2.0G 2007-01-16 20:47 second_half-40ecd8feb0950d04aeeae8cce61e1c60b311007e.pack	04:48
corecode	so, uhm	04:48
	how does git know in which pack to look?	04:48
	keeps the index in memory?	04:49
spearce	corecode: *correct. when we scan the packs directory we mmap all of the .idx files in it.**	04:50
	we then search them in a linked list for a given object.	04:50
corecode	i can't git-fetch --reference?	04:51
	sad.	04:51
spearce	hmm. the problem with --reference on git-fetch is that's implying we can get the data from the --reference directory. but we need to copy it into this directory (the one you are fetching into) anyway, don't we?	04:52
corecode	error: no such remote ref refs/heads/window-mapping2	04:54
	:/	04:54
	how do i fix that?	04:54
	corecode waits for majordomo to reply	04:55
spearce	your .git/remotes/origin or .git/config is stale with an old Pull: or fetch line. delete it.	04:55
	i removed that branch from my repo.or.cz repository, the code is in mainline git (1.5.0-rc1).	04:55
corecode	hm.	04:56
	i understand, but from a user perspective it is not exactly friendly	04:56
	also, how would i tell git to fetch all (new) refs?	04:56
	so now i got a new origin head	04:58
	i wonder how to forward my master	04:58
spearce	are you using 1.5.0-rc0 or later?	04:59
corecode	1.4.4.4	04:59
spearce	in 1.5.0 we changed the fetch/Pull: syntax so you can glob it: fetch = refs/heads/:refs/remotes/origin/	04:59
corecode	but i could as well go to 1.5	04:59
spearce	then you don't get this error, and it automatically picks up new remote branches.	04:59
corecode	ah	04:59
	so	04:59
	do you have all your code in one repo/workdir?	05:00
	hg made me use separate dirs for every chicken shit	05:00
spearce	yea, i keep everything in one git working directory and flip back and forth between branches at will.	05:02
	much, much faster.	05:02
	(than using different working directories).	05:02
	that globbing fetch is one of those "features" we did rather than rewrite command line parsing. :)	05:02
clee	# du -hs .git/objects	05:03
	3.1G .git/objects	05:03
	:D	05:03
	10GB -> 3.1GB	05:03
	not bad.	05:03
	not bad at all.	05:03
DrNick	how big is the SVN repo?	05:04
clee	the output from git-rev-list HEAD is the same as it was with the original gfi packs	05:04
	so I think I win	05:04
	DrNick: the SVN repo as of that exact revision was 15GB.	05:04
spearce	clee: good, you didn't miss anything. :)	05:04
DrNick	nice	05:04
	how thorough is the SVN import?	05:05
clee	missing all of the branches and tags.	05:05
	but it has every single revision from /trunk/	05:05
	which, it turns out, is 362838 commits	05:05
	→ gitster joined	05:06
clee	gitster: took a few hours to repack, but the KDE import I did is down to 3.1GB	05:06
corecode	anybody have the line to filter the git mailing list on?	05:06
	some majordomo stuff	05:06
clee	corecode: List-Id:.*git ?	05:06
corecode	it sends List-Id?	05:06
spearce	X-Mailing-List: [email@hidden.address]	05:07
clee	I've got the X-Mailing-List header and also:	05:08
	Sender:git-owner@vger.kernel.org	05:08
corecode	thanks	05:09
	→ rkaway2 joined	05:09
gitster	so what's still missing for 1.5.0?	05:09
spearce	gitster: with the exception of some sort of `git reflog show` (which i had hoped we wouold have) i think everything else is done.	05:10
corecode	fastimport also in?	05:15
spearce	no. it probably could go in, its a clean merge with no impact.	05:16
corecode	and without documentation :)	05:16
spearce	yes. i don't like to contribute undocumented stuff if i can avoid it.	05:16
gitster	My question was really about stale documents.	05:16
spearce	i can't answer that, i don't tend to read out documentation. :)	05:17
gitster	I think gfi is a piece complex enough that needs a clean frontend or two as examples to accompany when it goes in.	05:17
spearce	that's what i was hoping too.	05:18
	clee thinks svn-fast-export is almost there	05:19
gitster	I've been wondering, if written in clean and concise language such as Python, how much code a most trivial gfi frontend that exports from a git branch would take... that kind of thing might be a good "tutorial" example.	05:20
spearce	clee's svn import in python was like 270 lines.	05:20
corecode	wow. git is making me crazy	05:20
	the simple things are complicated	05:21
clee	spearce: LIAR	05:21
	spearce: it was 155 lines	05:21
	and in C it's only 188	05:21
	;)	05:21
corecode	i just want to pull spearce's fastforward repo into my repo	05:21
	fastimport*	05:21
	and refs/heads vs branches still makes me fuzzy	05:22
spearce	git repo-config remote.gfi.url git://repo.or.cz/git/fastimport.git	05:22
	git repo-config remote.gfi.fetch +refs/heads/:refs/remotes/gfi/	05:23
	git fetch gfi	05:23
	refs/heads are branches	05:23
gitster	Do you need the two lines if you just are interested in the current gfi?	05:23
clee	damn. I was hoping that I could fit the entire KDE git repo into 2GB.	05:24
	(so it would fit on my USB flash drive.)	05:24
corecode	spearce: yes, i know. it is just the nomenclature which confuses me	05:24
spearce	gitster: i don't understand the question, current gfi is my master branch in fastimport.git on repo.or.cz... its based on current master in git.git.	05:24
gitster	I know. I just did;	05:24
	git pull git://repo.or.cz/git/fastimport.git/	05:25
	Single command. Cannot be simpler and no confusing "nomenclature".	05:25
spearce	ah, good point.	05:25
corecode	gitster: but that will forward my master, no?	05:25
spearce	your current branch.	05:26
gitster	Yes, if you do not like what happened, you can "reset --hard ORIG_HEAD".	05:26
corecode	gitster: and if i want to pull again, i will need to enter this again	05:26
spearce	clee: probably unlikely, even with very long (e.g 25) delta chains.	05:26
gitster	so?	05:27
spearce	entering common urls frequently sucks. :)	05:27
gitster	of course. But in distributed workflow, ad-hoc promiscous pulls should be encouraged more ;-).	05:28
	as opposed to "always tracking him because he is my master".	05:28
spearce	yes. like the f'ing patch i got today that was whitespace damaged. much easier if i coulda just pulled it.	05:28
gitster	I did not know if corecode wanted to "track" you, or just wanted to take a peek.	05:29
corecode	hm. .git/remotes/ vs .git/config?	05:29
	gitster: track	05:29
spearce	.git/remotes vs .git/config is almost like saying which side of the bread do you like to butter, the top or the bottom.	05:29
gitster	either is fine, people on the list seemed to like .git/config better, so clone made with 1.5.0 uses config by default.	05:29
corecode	so, like refs/heads vs branches	05:29
	i guess maybe this is too much choice	05:30
gitster	.git/remotes was used earlier and is still supported but what could be	05:30
corecode	gitster: i noticed that pack.h uses unsigned ints for the struct definition instead of uint32_t	05:30
gitster	expressed with .git/config is richer, so we stopped adding new features to	05:30
	.git/remotes/.	05:31
	corecode: I am not interested hearing about them without patch -- I am aware of them fine, thanks.	05:31
corecode	yah, just checking	05:32
	no problem doing patches	05:32
gitster	fair amount of code assumes int is 4-byte and long is either 4 or 8 depending on the platform.	05:32
corecode	yah, pitty	05:34
	Warning: No merge candidate found because value of config option "branch.master.merge" does not match any remote branch fetched.	05:34
	wuh?	05:34
gitster	"git fetch origin master" (replace "origin" with whatever you call shawn's gfi repo)	05:35
	s/fetch/pull/	05:35
	or, define "branch.master.merge = refs/heads/master" in .git/config, perhaps.	05:36
	depends on what you want to do.	05:36
corecode	well, i don't know	05:36
	i doubt that i will be able to advocate git if i don't understand it myself	05:36
gitster	If you will only be interested in shawn's gfi, then defining branch..remote and branch..merge so that you can say "git pull" (without any args) to always pull from there would make sense. On the other hand, if you will be interested in different things at different times, that kind of shorthand is not very useful.	05:38
	gitster agrees that advocating or teaching to others what one does not understand does not make much sense...	05:39
spearce	of course they say you really learn something if you teach to another.	05:40
gitster	sure.	05:40
corecode	heh	05:40
	okay	05:40
	i just fear that other people will be really confused	05:40
gitster	by the way, I've followed up the revert/cherry-pick change to teach "checkout -m" branch switching to use merge-recursive, so that we can follow renames while carrying local changes forward ;-)	05:41
spearce	heh. very nice. i was thinking today doing a 'checkout -m' that its too bad it wasn't using merge-recursive, as the output was more verbose than i wanted...	05:41
	(my merge.verbosity=1)	05:42
	did you setup GITHEAD_* for that invocation?	05:42
gitster	yes.	05:43
spearce	sweet.	05:43
	does anything even use merge-resolve anymore? (in tree anyway)	05:44
gitster	applypatch hence applymbox. but not am	05:45
spearce	heh. we can't break those, otherwise Linus' workflow would grind to a halt.	05:46
gitster	I personally doubt Linus uses -3 so he would not be using resolve there...	05:47
spearce	actually you can probably put recursive in there to replace resolve just like we did in am and it wouldn't bother anyone. what would would be removing applymbox in favor of am only.	05:48
gitster	that's my long term plan -- leave applymbox, keep it working but without enhancement and have gittus who would be the last user of the script switch and then remove it ;-).	05:49
spearce	i'm really happy with how merge is behaving now, between going right into merge-recursive and its controllable verbosity. very nice series of changes there.	05:50
	to me anyway. :)	05:51
gitster	heh, that's what you did.	05:51
spearce	i know. :-)	05:51
	i'm glad you gave me the verbosity levels though, i was just going to gut it.	05:51
corecode	gitster: this use of global variables is ugly, btw	05:53
	gitster: is that on the TODO to be changed?	05:54
	→ lyakh joined	05:58
spearce	corecode: in something like index-pack.c its not a huge issue, that isn't library code. what's worse is the object lists. those make it reallly difficult to reuse the important revision walking routines in a library setting.	05:59
corecode	argument passing via global variables is really ugly	05:59
gitster	it is a small part of more important issue: libification.	05:59
	I currently lack energy and inclination to rehash the issue for you, but	06:00
	it has come up at least three times on the list.	06:00
	ask gmane for things I wrote with keywords like "run-once mentality".	06:00
corecode	yah	06:00
	so that is a "yes, on todo"	06:01
gitster	"no, not on MY todo right now during 1.5.0 stabilization period" ;-).	06:01
corecode	yah	06:01
	just generally seen as a good idea	06:01
spearce	yes. people just need to find it needed, so they work on it.	06:02
gitster	Absolutely. The static-global (object layer and per repository data structures in general) is one. Another is error return (we do seem to allow die and error handler to be installed by the library using application, though).	06:03
spearce	gitster: but we assume the die routine aborts the caller. which means either longjmp, or c++ exceptions, or kill the current process. which is not library friendly.	06:03
corecode	yah	06:04
	DrNick still doesn't get how libpng manages while using longjmp()	06:04
gitster	longjmp is not bad per-se. You need to be careful about leaving garbage behind, though.	06:05
corecode	you could add a setlongjmp() on every API entry	06:05
	and have die() longjmp() there so that the API can return a failure	06:05
	you won't be able to clean up though	06:05
	sorry to repeat your point :)	06:06
DrNick	attribute((destructor))	06:06
gitster	a related issue is atexit() handlers.	06:06
DrNick	if you really want to kill portability	06:06
gitster	Hmm. "git remote" may need "edit" subcommand before we go 1.5.0...	06:08
corecode	oh, there are a bunch of almost-identical do { xread() } while(read < needed)	06:08
spearce	those should be converted to read_in_full().	06:09
gitster	If you are into templates, there are also bunch of identical binary search and insert that you could refactor.	06:09
spearce	assuming they are requiring the total read == needed.	06:09
corecode	wow. returning NULL on success or const char * on error is also new to me :)	06:09
	gmake: *** [t3402-rebase-merge.sh] Error 1	06:14
	is that a known issue?	06:14
spearce	corecode in my gfi branch?	06:15
corecode	no	06:15
	git.git/master	06:15
gitster	Of course not in my environment -- but I do not have to type "gmake", so you might be on something non GNU.	06:15
spearce	i had thought that broke recently but that it was fixed.	06:15
corecode	yah, i'm on non-linux	06:16
spearce	gfi is behind master so the gfi branch could be broken in some non-gfi areas.	06:16
gitster	We tend to get less coverage on non-Linux, so testing and reporting is very much appreciated.	06:16
corecode	sure thing	06:16
	ah.	06:23
	git-rebase has perl fixed at /usr/bin/perl	06:24
	is it a good idea to use a absolute path there?	06:24
spearce	git-rebase invokes perl?	06:25
	we try not to hardcode perl, so the user can point us to a location other than /usr/bin/perl when they compile git.	06:25
corecode	yes, ah	06:26
	i see	06:26
	on a second run a set perl	06:26
	maybe Makefile could try `which perl` if PERL_PATH is not set	06:27
gitster	Don't use 'which' in scripts, ever.	06:28
corecode	no?	06:29
	why not?	06:29
gitster	Have you used Solaris?	06:29
corecode	no	06:29
spearce	yea, it sucks there.	06:29
corecode	sad.	06:29
DrNick	$ which ls	06:29
	alias ls='ls --color=tty'	06:29
	/bin/ls	06:29
corecode	yah	06:29
	sure, alias is alias	06:29
DrNick	of course that's the shell builtin which and not /usr/bin/which	06:30
gitster	Usually 'which' is fine, but if I recall correctly their which did not fail properly when there is no such thing on the path and screwed up automatic detection.	06:30
DrNick	what about env?	06:30
corecode	yah, that's the other possibility	06:30
spearce	probably just fine to have the Makefile verify PERL_PATH is working.	06:31
corecode	or simply don't hardcode perl	06:31
gitster	I think that env is a disease. we are doing token replacement in the Makefile so we can afford to.	06:31
corecode	spearce: yes, i wanted to suggest that	06:31
spearce	that way the build stops and asks the user to set it.	06:31
gitster	cross compilation?	06:31
	... don't take it seriously -- just trying to be difficult ;-).	06:32
corecode	well	06:32
	of course if PERL_PATH is set, there is no need to check that	06:32
	just bail if there is no /usr/bin/perl	06:32
gitster	maybe "make sanity"	06:32
corecode	AND PERL_PATH is not set	06:32
spearce	unlike svn, git builds in just a couple of minutes. and if you have to cross-compile it, uh, maybe git isn't the best tool for the target if it lacks a compiler.	06:33
gitster	Or "make test" could do that.	06:33
corecode	better make it fail on any	06:33
gitster	Or teach people to read INSTALL ;-)	06:33
corecode	well, i set PERL_PATH, but didn't make clean	06:34
gitster	Hmm. We seem to be careful about CFLAGS changes but maybe PERL_PATH is not tracked.	06:34
corecode	i guess there is no .gitrc	06:34
gitster	... and I am not sure if it is worth doing.	06:35
corecode	i mean ~/.gitrc	06:35
spearce	corecode: ~/.gitconfig is our personal preference file. its merged with .git/config on the fly.	06:35
	but doesn't affect compilation.	06:35
gitster	Probably Documentation/config.txt needs enhancement (or corecode needs to be taught to read before speak).	06:35
	I do not think ~/.rc or ~/.config should affect building.	06:36
	Documentation/config.txt does not seem to talk about $HOME/.gitconfig.	06:36
	Sigh...	06:36
spearce	gitster: extern void pack_report(); or extern void pack_report(void)? (see recent patch just posted).	06:37
gitster	I think the latter is what we do in the rest of the code.	06:37
spearce	nor does Documentation/config.txt speak of $GIT_DIR/config.	06:37
	ah, ok, so my mistake. thanks.	06:38
corecode	oh that wicked	06:38
	gitster: i read the man pages	06:38
gitster	Good thing we have a competent people who hasn't lost git virginity.	06:38
	IOW, I really appreciate your presence ;-).	06:38
	corecode looks puzzled	06:38
corecode	:D	06:38
	you're welcome	06:38
spearce	we need to keep a steady stream of 'em. :)	06:39
corecode	so, how is it with commit messages	06:41
	is something like	06:41
	Use fixed-size integers for the on-disk pack structure.	06:41
	enough	06:41
	or is it common to add more text for that	06:41
gitster	what commit are you talking about?	06:41
corecode	one i want to make	06:41
spearce	its a good first line, i would try to explain why possibly variable sized ones are bad in an additional paragraph below it.	06:41
	but i can also be rather longwinded. :)	06:42
	spearce thinks corecode is trying to patch struct pack_header.	06:42
corecode	yes	06:42
	i guess you have to separate the paragraphs with a newline, or what was it what i read in common git mistakes?	06:42
spearce	you don't have to, but it really helps readability.	06:43
	e.g. git show cf69fd49ec815780080dc6a4ee237eee5ffe8745	06:43
	aside from the leading tab on each line, that's exactly what i put in my editor.	06:43
corecode	and possibly the signed-off-by	06:44
spearce	right, i put in my sbo. junio added his when he applied it.	06:44
gitster	Ok, I added a few sentences at the beginning of config.txt; thanks.	06:47
	Would it make sense to suggest commit message convention in git-commit.txt, perhaps? Copy a paragraph from ll.88- in tutorial.txt.	06:50
spearce	yes, i think that makes a lot of sense. hate to copy 77 lines but it would probably help a number of users.	06:50
	oh, 5 lines. ;-)	06:51
gitster	I meant the paragraph starting at line 88, sorry.	06:51
	done.	06:51
spearce	so i guess there were things missing from 1.5.0. :)	06:54
gitster	This week is slow due to LCA, so I am debating with myself if I should do an -rc2 tomorrow or leave that til the weekend.	06:55
spearce	you can debate with yourself, i'd wait til the weekend. we just did -rc1 recently.	06:55
gitster	(LCA does not necessarily make git slow, but --cc was done during LCA)	06:56
spearce	hehe.	06:56
	get a bunch of smart motivated people together.. interesting results come!	06:56
gitster	I saw Pasky drop by for a short time tonight ...	06:56
	I am wondering if somebody wants to do git tutorial or BOF at OLS this summer.	06:57
spearce	yea. popped in just for a minute. managed to fix my packfile on repo.or.cz, its perms were completely whacky. then as quick as he came in, he popped out.	06:57
	i'd do one, but i'm probably not going to either.	06:58
gitster	Hmm. 62 commits excluding merges since -rc1. Surely we are slow this week.	06:59
spearce	folks are busy with other stuff i guess. i know i am.	07:00
gitster	likewise.	07:00
spearce	'course i'm also trying to stay away from things you might be tempted to merge, so 1.5 can stablize and get out.	07:01
gitster	I need an evil-rerere.	07:04
spearce	normal rerere doesn't handle evil merge conflict resolutions?	07:05
	or was it not a conflict, but still needs to be done.	07:06
gitster	This merge does not textually conflict (I am merging jc/fetch to 'next').	07:06
	I end up doing the 'commit --amend' to introduce the same evil-mege change.	07:06
spearce	but it would be nice if rerere recalled it. :)	07:07
gitster	(background. I use in_merge_bases() in builtin-fetch--tool.c which is a new file. the function's signature is different between master and next, and jc/fetch is forked from master).	07:07
spearce	yea, i saw that in pu.	07:08
niv	uh... next is behind master.. :)	07:13
spearce	yea, sometimes that happens when junio has master ready before next and pushes it out first.	07:14
gitster	It would stay that way for a while, I would expect.	07:16
niv	you force the people to use master then G	07:17
	(-the)	07:17
gitster	It's not about forcing. No new topic has started that is worth to be in 'next' recently.	07:18
spearce	i think the expectation is that next is always some sort of superset of master. but the only way i've really ever seen next get refreshed with some from master is when topics go into it.	07:19
gitster	And I already asked very politely to people who follow 'next' usually to follow 'master' in the meantime ;-).	07:19
spearce	which i started doing. :)	07:19
niv	yes, you did :)	07:19
gitster	Well, it seems that I won't be doing -rc2 tomorrow, so instead I'd bring 'next' up-to-date.	07:21
	→ bronson_ joined	07:35
	→ gitster joined	07:39
clee	gitster: OC? orange county?	07:41
	oklahoma city?	07:41
gitster	that's ISP's exchange and does not have much to do with where I am but I am guessing that is at orange county.	07:42
	→ ferdy joined	08:37
	→ chris2 joined	10:12
Romster	needs update, how do i revert it to head version? git reset dosn't do it do i need to --force it?	10:37
	nevermind git-reset --hard did it for me.	10:42
	→ mchehab joined	10:51
	→ benlau joined	12:18
	→ kynde joined	12:22
	→ nud joined	12:58
	→ timlarson_ joined	13:54
	→ mcheha1 joined	14:19
	→ Romster joined	14:34
	→ benlau joined	14:38
	→ sgrimm joined	14:46
	→ kendy joined	14:53
kendy	Hi there!	14:54
	Please is there a restriction of the branch/tag name in git?	14:54
	I'm converting a rather large CVS repository to git (using git-cvsimport), and I got "fatal: Not a valid object name ausetestcwswarumgehtunderscorenicht"	14:56
pasky	omg :)	14:56
	that's perverse, you know	14:56
kendy	pasky: Nazdar! ;-)	14:56
pasky	ahoj :)	14:56
	but I don't think there's length restriction	14:56
	more likely a bug in git-cvsimport, but no time to look at it closer now :(	14:57
	if noone replies, please drop a mail at the mailing list	14:57
kendy	pasky: I've restricted it to 30 chars so far, but got another error now ;-(	14:57
	The other error was:	14:57
	error: char94: could not verify tag name	14:58
	fatal: invalid tag signature file	14:58
	Use of uninitialized value in scalar chomp at /local/bin/git-cvsimport.ooo line 718.	14:58
	Cannot create tag object CWS_SRX644_AUSE_TESTCWS2_ROOT :	14:58
	Unfortunately I don't see where is the char #94 ;-)	14:58
	→ krh joined	15:18
kendy	Hmm, the latter is caused by my workaround, but the former still interests me... ;-)	15:19
	→ mchehab joined	16:09
	→ krh joined	16:14
	→ mcheha2 joined	16:16
	→ timlarson__ joined	16:28
	→ timlarson___ joined	16:29
	→ kanru joined	16:38
	← kendy left	16:40
	→ Eludias joined	17:11
	→ timlarson___ joined	17:11
	timlarson___ → timlarson_	17:14
	→ lyakh joined	18:27
	→ meyering joined	18:28
	→ Eludias joined	19:04
	→ lyakh joined	19:44
	→ nud joined	19:48
	→ krh joined	19:51
	→ robinr joined	20:10
	→ Romster joined	21:13
	→ sgrimm joined	21:17
clee	so it takes 'git blame' about fifteen to twenty seconds to figure out the history for any randomly-chosen file from the KDE repo I've got.	21:22
	I think this is pretty impressive	21:23
	but in absolute terms, 15-20 seconds is kinda slow.	21:23
nud	clee: how does it compare with a similar functionnality in svn ?	21:23
clee	nud: I have no idea.	21:24
	good question. :)	21:24
	clee does a test	21:24
nud	I like asking good questions, I'm just not good at it ;-)	21:24
clee	hm.	21:29
	with a local svn repo, 'time svn blame kdemainwindow.cpp' takes about 0.8 seconds.	21:29
	er, kmainwindow.cpp.	21:30
nud	and time git blame kdemainwindow.cpp ? 15s ?	21:30
clee	is there any way to get 'git-blame' to not spawn $PAGER?	21:33
nud	git-blame \| cat ?	21:33
clee	ah	21:35
	export PAGER=cat :)	21:35
	git blame kmainwindow.cpp 76.08s user 0.34s system 99% cpu 1:16.45 total	21:37
	way longer than the fifteen or twenty seconds I thought it was.	21:37
	surely that can be made faster.	21:37
nud	it probably depends on how much data you need to get from the hard disk	21:38
sgrimm	That $PAGER thing really annoys one of the guys here who uses Emacs as his terminal program.	21:38
	clee shrugs	21:38
clee	it's a LOT slower here than svn.	21:38
	which is amusing.	21:38
nud	is your git-repo complete now ?	21:42
clee	yes.	21:42
	kind of.	21:42
niv	it could depend on how fast your terminal is.	21:42
clee	it does not have every single KDE revision in it	21:43
	no, no.	21:43
	I'm redirecting to /dev/null.	21:43
niv	oh then.	21:43
	→ robfitz joined	22:05
	dwmw2_gone → dwmw2_lca	22:20
	→ nud_ joined	22:42
	→ znephf joined	22:43
	→ Debolaz joined	22:58
	→ pg joined	23:01
pg	evening, as a total newcomer to git can someone please explain how I switch to a new existing branch when I have un-commited changes in the current branch that I do not wish to commit just yet please - seem like I can see no way to specify the physical directory the checkout files are placed in, am I missing something ?	23:03
niv	you want to create a new branch?	23:05
	or you want to change to an existing branch?	23:06
pg	change to an existing branch without loosing the un-commited changes I have in the current branch but without those changes being in the new checkout	23:06
	since they are unrelated.	23:06
robinr	pg: git checkout -m	23:07
pg	I thought the checkout -m performed a merge and thus would include my existing changes in the new branch checkout	23:08
robinr	if you're paranoid, save the changes using git-diff and apply on the new branch with git-apply	23:08
gitster	I do not think that is what pg is asking but I am not sure...	23:08
pg	this is what I am wanting to avoid	23:09
clee	I think what pg wants is something like:	23:09
	git diff > current-branch.changes	23:09
gitster	Can you describe it in terms of "here is what I would do in CVS to do what I want to do"?	23:09
pg	ok sure	23:09
clee	git reset --hard	23:09
	git checkout branchname	23:09
pg	current branch is "xxx-sub project" and has some un-commited changes	23:10
robinr	clee: isn' it the same?	23:10
clee	robinr: no.	23:10
	robinr: git-checkout -m will merge the changes from the current branch	23:10
robinr	note the bases in the merge	23:10
clee	he doesn't want that	23:10
pg	I need to change and work on "yyy-branch" for a fix but I want to be able to return to "xxx-sub-project" when I have finished there	23:10
	If I could checkout yyy-branch to a different directory and work there it would be what I need I think	23:11
gitster	the way we do that (assuming I am understanding you correctly,	23:11
	the fix to yyy-branch is something small you noticed while working on	23:11
	xxx-branch) in git is...	23:11
robinr	the base version is not the same as in a normal merge	23:12
gitster	(1) typically, a small unrelated thing does not overlap with your existing change for xxx-branch	23:12
	(2) hence we do not mind taking the working tree change while switching branches -- as long as we do not include the change to the commit we are going to make in yyy-branch.	23:12
	So if you have already modified file A B C in your working tree (and you are working on xxx-branch), and noticed something in file D that needs to be fixed for yyy-branch,	23:13
	you would do "git checkout yyy-branch", do your fix there to file D, and then commit only that change (with "edit D; git add D; git commit" -- note that the last "git commit" does not have -a nor any filename), and come back with "git checkout xxx-branch".	23:14
pg	gitster: almost there except for 1) new change in yyy-branch may include changes to same files and 2) it may be a while in the fixing [i.e. I want to be able to work on both and switch between them freely if possible without extra commits just to same intermediate work]	23:14
gitster	That is how git is normally used by experts.	23:14
	If you are on the other hand used to multi-task and rather want to have two working trees, then	23:15
	you could make a cheap local clone. Say you are working on xxx-branch in directory D1 (so `pwd` would say D1, and D1/.git is where your repository metadata lives),	23:16
	and without disturbing what's there you would do: "cd ..; git clone -s -l D1 D2".	23:16
	Then "cd D2 && git checkout yyy-branch" and do your fix there.	23:16
pg	now that workflow with the file D small change I like, I will have to remember I can do that :) As I said very new to git	23:17
gitster	The fix may take time and while you are compiling or running test in D2 you may come back and keep working on xxx-branch in D1.	23:17
pg	Ah, that local clone idea I thought off and just wondered if there was a better way of doing things	23:17
	so the local clone is the correct way to do this in git -- yes ?	23:17
gitster	Not multi-tasking is the correct way if you ask Linus and me -- we don't multitask.	23:18
	But the thing is, there is no single "correct way" forced upon you.	23:18
	If I were as good at multi-tasking as you are, I would do the local cloning (one branch per repo).	23:19
pg	believe me not multi-tasking would be nice but not an option for me in the real world	23:19
	hmm, just looking at the help for the -s option and I am not sure I understand what it does for me, can you elaborate please	23:20
gitster	The new repository will borrow objects from the original one (which implies that D2 will be hosed if you decide to "rm -fr D1" in my previous example).	23:23
	→ Debolaz2 joined	23:23
gitster	... which is a storage optimization (and saves time while cloning).	23:23
pg	ah, nice	23:23
clee	doesn't 'git-clone -l' use hardlinks?	23:23
pg	Have only been playing with git for a day or so and I have to say it does feel very nice the more I find out about ot	23:24
gitster	-s saves even more -- it does not even use hardlink.	23:24
	it instead uses alternates mechanism.	23:24
clee	gitster: right, but -s is crazy and prone to failure if you remove stuff from D1	23:24
	I can't imagine that, on a local disk, it's that much of a win :)	23:24
	hardlinks are cheap and fast and awesome	23:24
gitster	nobody forces you to use -s.	23:24
clee	YOU'RE FORCING ME TO USE -s AND I HATE IT	23:25
	... oh, no, you're right. :)	23:25
	anyway. git-blame is slow.	23:26
	gitster: like, a lot slower than svn blame.	23:26
	and I get this when I run git annotate:	23:26
gitster	-s makes sense for the cheap local clone workflow pg wants, but as you say you need to be careful.	23:26
clee	root git/kdelibs/kdeui # git annotate kmenubar.cpp	23:26
	fatal: bad default revision 'HEAD'	23:26
pg	well I am gona nip off now and try this out -- many thanks for the help, it is much appreciated	23:26
clee	if I do 'git blame kmenubar.cpp' it works	23:26
	→ Debolaz joined	23:28
clee	(but very very slowly)	23:28
	svn blame kmenubar.cpp 0.64s user 1.44s system 36% cpu 5.635 total	23:28
	git-blame kmenubar.cpp 83.34s user 0.34s system 99% cpu 1:23.90 total	23:28
	→ Debolaz joined	23:32
gitster	that's a good reason for you to stick with svn, I suppose ;-).	23:33
clee	I'm just collecting numbers. :)	23:33
	are there any known easy targets for optimization in git-blame?	23:33
gitster	I do not think blame has seriously optimized yet -- you are welcome to take a crack at it. I think I've plucked all the low hanging fruits, though.	23:34
clee	you bastard. ;)	23:34
gitster	If you go back to the mailing list archive, you see posts by Linus on tradeoffs he made while designing the basic data structure of git.	23:34
clee	it takes about 21 minutes to verify the entire pack, btw	23:35
gitster	and per-path operation like annotate/blame is not one of the things it was optimized for.	23:35
clee	git verify-pack 1144.12s user 102.49s system 97% cpu 21:23.84 total	23:35
gitster	Is that a good thing or bad thing?	23:35
	gitster notices the patch he sent out to make .patch the default for format-patch does not appear on the mailing list...	23:36
clee	I think it's pretty impressive for a 3GB pack	23:36
	is verify-pack recursive?	23:37
gitster	explain "recursive".	23:37
clee	(IE, is it as optimized as it could be, or is there some work that could be done there?)	23:37
	well, I know that you start off with the most recent commit, HEAD, right	23:37
	and then you find the parent	23:37
	and verify it	23:37
	and verify it's parent, etc	23:37
	right?	23:37
gitster	It needs to be exhaustive, I think.	23:37
	But it does not use ancestry chain IIRC.	23:38
	dwmw2_lca → dwmw2_gone	23:38
gitster	What it verifies can be seen in pack-check.c; it makes sure that .idx is correct and the data that comes out of the packfile is not corrupt.	23:39
	clee: you were the one who did the frontend for Shawn's gfi to import that huge pack, right?	23:40
clee	yep	23:40
gitster	then you know a packfile is not about ancestry already --- who was I giving lecture on it X-<.	23:41
clee	yep.	23:41
gitster	For things like full KDE, what would have been nicer was a reasonable subproject support. I do not think tracking set of independent applications in a single tree fully sync'ed makes much sense.	23:44
clee	yeah.	23:44
	I'm interested in any developments in splitting out a gigantic repo like this into subprojects	23:44
	gitster: to be fair, with KDE, we've moved a lot of stuff around between modules	23:45
	and it's nice to not lose history	23:45
	like, some libraries that started off in kdebase are now in kdelibs	23:45
	and some apps and libs from kdenetwork moved to kdepim	23:45
	that sort of t hing	23:45
	er, thing	23:45
robinr	clee: have you followed the threads on the topic on the mailing list?	23:46
clee	robinr: no.	23:47
robinr	look them up. Most of it is about indepdendent submodules though	23:47
clee	I dunno. I want real modules.	23:48
	but I also want to be able to follow history of files that move between them.	23:48
robinr	me too	23:48
gitster	me three ;-).	23:50
robinr	i'm all four it	23:50
	the problem is that people want modules for widely different reason	23:51
	is anyone using git-cvsexportcommit besides me? (someone wrote it originally of course). The only thing missing now is getting rid the need for a huge CVS checkout.	23:53
	it should be possible to work only on the files involved.	23:54
gitster	I wonder if you can use the same directory as both CVS checkout and git working tree..	23:55
robinr	sometimes, but a nice thing with the current state is that you do not necessarily have to commit the same "base"	23:58
	you can commit to any CVS branch as long as the patches apply cleanly	23:59
	I like that	23:59
gitster	and overlapping working tree does not allow that how?	23:59

Logs Search ←Prev date Next date→

Channels Documentation