IRCloggy #git 2007-06-11

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-06-11
jmspeex	normalperson: For my git-svn problems, would it work if I clone my repository and when I want to commit to svn, I push to that cloned svn repository and do a set-tree from there?	00:00
	the idea being that I wouldn't see the non-linear history stuff in my main working directory.	00:01
mugwump	you will see the non-linear history once you start pulling in svn changes	00:03
	if it's export only, you don't need to pull them in	00:03
	so if that's what you want what you suggest is fine	00:03
normalperson	jmspeex: probably, but I get the feeling what you're doing (or want to do) is way more complicated than it has to be	00:03
	→ babbage joined	00:04
babbage	I'm a dumbass	00:04
	I just merged a branch when I didn't want to. How can I undo the screwup?	00:05
jmspeex	normalperson: I think you think what I'm trying to do is very complicated. In reality, all I want to do it keep my old svn tree sort of up-to-date for others to use. I don't even want to pull from it.	00:05
mugwump	babbage: easy! just make a new branch from before where you merged	00:05
	and switch to that	00:05
	→ weitzman joined	00:06
babbage	mugwump: then what?	00:06
normalperson	jmspeex: having two separate histories for the same branch is complicated...	00:06
mugwump	well the branch you're working on won't have the merge you didn't want	00:06
	you can delete the old one if you like	00:07
normalperson	jmspeex: really, a 1:1 mapping between your git repository and the svn one is the simplest	00:07
babbage	I would prefer not to delete the branch, I think.	00:07
normalperson	but I think your two repository idea with set-tree would work	00:07
babbage	Can't I just roll back the commit I just made?	00:07
mugwump	sure, git-reset is the command	00:08
	eg, make sure you've got the ID right with git-show, then git-reset --hard ID (this will throw away any uncommitted local changes)	00:08
jmspeex	normalperson: the thing is that I've already had two different problems with git-svn that were probably due to me not using it 100% right. To be honest, as long as the svn head shows the latest stuff, I don't care much about the rest.	00:08
mugwump	jmspeex: you don't need to pull from svn -> git then?	00:09
jmspeex	normalperson: why do you say "having two separate histories for the same branch is complicated"? where would I have two histories?	00:09
	mugwump: no, I want svn to be write-only	00:09
	(i.e. svn will be mainly for windows users)	00:10
	→ rphillips joined	00:10
normalperson	jmspeex: repository one: where you do work, you push to repository two from here	00:10
mugwump	just use set-tree/commit-diff and never use rebase/pull from svn then	00:10
normalperson	jmspeex: in repository two, you do set-tree	00:10
babbage	My bad merge commit is ab2ec8b. Do I just do "git reset --hard ab2ec8b" ?	00:10
jmspeex	normalperson: wouldn't repository 2 have the same history if I use set-tree and not dcommit?	00:10
normalperson	jmspeex: well, commit-diff and set-tree won't work without the latest HEAD on svn	00:10
mugwump	no it will be one of the parents. I think ab2ec8b^1 is the left hand parent	00:11
laj	normalperson: what about a script='dcommit+git-push' (and ban manuel git-push), would'nt that keep them in sync	00:11
babbage	mugwump: left hand parent?	00:11
jmspeex	normalperson: I thought set-tree was just overwriting...	00:11
mugwump	the two parents are equivalent, but one of them is listed first	00:11
jmspeex	What do I need to do on the second tree then?	00:11
normalperson	jmspeex: yes, but it needs a base to do the diff against	00:11
	laj: kind of hard to ban a command, no?	00:12
laj	yes but for his workflow :)	00:12
mugwump	maybe a dcommit hook?	00:13
jmspeex	normalperson: BTW, will set-tree push my changes one at a time or will they end up as one big commit?	00:13
normalperson	jmspeex: set-tree foo..bar => one change at a time, set-tree bar => one big commit	00:13
	jmspeex: you'll also need to remember the -i flag if your remote ref is anything other than refs/remotes/git-svn	00:13
	jmspeex: $GIT_SVN_ID == -i $foo	00:14
jmspeex	If I use a copy (not clone) of my current repository (which I'm already using with git-svn), I don't need to do that (-i), right?	00:15
normalperson	jmspeex: -i determines which remote branch of svn you're using... (run "git branch -r" to list all remote refs)	00:16
	you'll probably see "git-svn" or "trunk" there, depending on how you imported from svn	00:16
jmspeex	normalperson: So what would be the list of commands I need to do after I've pushed to my second repository?	00:17
	Oh, right, it's "trunk"	00:17
normalperson	jmspeex: ok, git-svn set-tree -i trunk master should work to get you one big commit	00:17
	replace master with whatever ref you're pushing to	00:17
jmspeex	So if I have 5 commits to push, I just use:	00:19
	git-svn set-tree -i trunk HEAD~5..HEAD	00:19
hharrison	normalperson: ok, mine appears to be up there	00:19
	users/hharrison/tempgcc.git on infradead.org	00:20
	That's the repo created by the simple git-svn clone ( 1) above)	00:21
normalperson	jmspeex: that works, too	00:21
hharrison	I didn't want to wait for my 2) above to finish, so it is an incomplete clone, could also put it up if you want	00:21
jmspeex	normalperson: you sound like "it works, but you should be doing something different".	00:22
normalperson	jmspeex: first example I gave: git-svn set-tree -i trunk trunk/master == one big commit	00:22
	git-svn set-tree -i trunk HEAD~5..HEAD == 5 small commits	00:23
	pick your poison :)	00:23
	jmspeex: I still recommend dcommit/rebase over set-tree	00:23
segher	jmspeex: i don't see why you want to keep the svn repo around at all, given that all development will be done on git	00:24
jmspeex	normalperson: I'd use dcommit if it didn't have to rewrite my local history and create all kinds of problems if I ever push to a git repository something that hasn't been dcommit-ted already.	00:24
normalperson	segher: he has windows users	00:24
jmspeex	exactly	00:24
segher	they can use gitweb	00:24
jmspeex	segher: plus it makes rillian happy because all the xiph source is in one svn repo :-)	00:25
segher	jmspeex: in one set of git repos if ralph isn't careful ;-)	00:25
normalperson	jmspeex: just push --force, rewriting local history isn't much a problem... every patch we email to the a mailing list for Junio or Linus to apply is rewriting history	00:25
jmspeex	normalperson: why is that?	00:26
normalperson	well, when I email a patch to Junio, he'll add a Signed-off-by: line to the commit message	00:26
	jmspeex: also, the Commit-date and Committer will be his, while the Author-date and Author name remain mine	00:27
	git distinguishes between Author and Committer	00:27
segher	not that committer is very useful	00:28
jmspeex	BTW, is there a way to "push" all branches to a remote repository? a bit like a reverse clone	00:28
babbage	git push --all ?	00:29
segher	you don't normally want to push all branches	00:30
	since many will be throwaway branches	00:30
normalperson	hharrison: r2545? ae736c01ac21e5cc4051a43ad1a48f93414fa0fb for both commands you gave	00:30
	hharrison: still cloning the git one	00:30
	hharrison: "(all.build): Add target $(GCC_PASSES) for xgcc."	00:31
hharrison	Sorry r2454	00:32
normalperson	well, if 2545 matches, then 2454 should definitely match...	00:32
hharrison	r2453 - b3255f1d6f83a92890652662c0611d7801ef1b9c	00:32
jmspeex	strange: I did a push and gitk didn	00:33
	't see the changes until I did a fetch of what I had just pulled	00:33
hharrison	On one branch: r2454 - d92489bddef7173cf8b56896f1b6f352875e901c	00:33
normalperson	hharrison: yup, and r2454 839eb76944c9f5f11c41d2583dd3eb77246fb642 on both	00:33
hharrison	On the other r2454 - 839eb76944c9f5f11c41d2583dd3eb77246fb642	00:33
normalperson	what trees did you get?	00:34
hharrison	same, 859ae6f...	00:34
	The only difference is the commit message	00:34
normalperson	hharrison: what was the commit message for d92489bddef7173cf8b56896f1b6f352875e901c ?	00:35
evan	normalperson: just curious, did you use svk before git?	00:35
normalperson	evan: not really, I tried it once but thought it was too complicated and slow	00:35
evan	and you were right.	00:36
normalperson	evan: I understood git by reading (and hacking) git-archimport, too, so my understanding of git is probably different than most users	00:36
evan	normalperson: heh	00:36
	normalperson: i worked on a ruby svk workalike for a while	00:37
normalperson	hharrison: was the commit message for d92489bddef7173cf8b56896f1b6f352875e901c also somewhere in the history for 839eb76944c9f5f11c41d2583dd3eb77246fb642 under a different -r?	00:38
hharrison	commit d92489bddef7173cf8b56896f1b6f352875e901c	00:38
	Author: rms <rms@138bc75d-0d04-0410-961f-82ee72b054a4>	00:38
	Date: Wed Oct 14 09:29:26 1992 +0000	00:38
	Get rid ^LDon't include sys/types.h. Avoid the names u_long, u_short, u_int	00:38
	record-inline.h renamed to record.h. Use gstdarg.h.	00:38
	Some comments and whitespace cleaned up. RCS headers removed.	00:38
	Record_t changed to struct record *.	00:38
	isa field of struct objc_class renamed to class_pointer.	00:38
		00:38
		00:38
	git-svn-id: svn://gcc.gnu.org/svn/gcc/trunk@2454 138bc75d-0d04-0410-961f-82e	00:38
	Whoops, sorry about the formatting	00:38
normalperson	hharrison: date-time and author matches	00:39
hharrison	Yeah, it's just the commit message, everything else is identical	00:39
normalperson	hharrison: any chance the admin for the repository changed the commit message?	00:40
hharrison	all the downstream trees/messages etc match, but after this of course the commits don't	00:40
normalperson	it's possible to edit rev-props in svn	00:40
hharrison	No clue, was a long time ago	00:40
	Any thoughts as to why my two invocations would pull different content?	00:40
normalperson	is that log entry anywhere in your history? because I don't see it...	00:41
hharrison	I only have one clone in that repo, pushing the other branch now	00:41
normalperson	hharrison: commit messages in svn repositories are not frozen in stone	00:41
	hharrison: an administrator can change them whenever they want	00:41
	did you fetch one before the other by any chance?	00:42
hharrison	So maybe between the time I cloned the first time and the second it was changed (just got unlucky in that 2-day period)	00:42
normalperson	hharrison: yeah	00:42
hharrison	I did the two clones show above in entirely separate repos	00:42
	I didn't fetch into the first one, I completely re-cloned with the -T -t -b version	00:43
normalperson	hharrison: yeah	00:43
hharrison	Doesn't matter really, other than the problems fetching the tags, I'm happy, just thought you might want the report	00:44
normalperson	hharrison: cool, if you get a chance could you ask the administrator(s) if there was a change?	00:44
hharrison	Now that I have them both I can always get creative with git-rebase and choose which history I want to keep	00:45
normalperson	cool	00:45
hharrison	after that a git-svn rebuild and I should be on my way, no?	00:46
normalperson	hharrison: hopefully :)	00:47
hharrison	Although I still would like to get your patched svn-perl so I can get the tags before the end of time	00:47
	There are a _lot_ of tags in there	00:47
	And I do not want to do a svn co for each	00:47
normalperson	yeah	00:48
	wait, didn't you already get that?	00:48
hharrison	See about 5 minutes after you left, it reliably crashes	00:48
normalperson	oh...	00:48
hharrison	So for now I commented out my svn-tags line in config and am just filling in the branches	00:49
normalperson	hharrison: I'll resume my fetches and see if I reproduce it	00:49
hharrison	That should only co once for each new branch, right?	00:49
normalperson	I'm off for now, need to do some stretches	00:49
hharrison	OK, I'll be here, about half-way to getting all of the branches imported	00:49
normalperson	shouldn't even need to, only the initial trunk needed it	00:49
	everything else should be a delta	00:50
hharrison	Well, I stil see an occasional svn co	00:50
	But it only happens when it hits a branch I haven't seen yet	00:50
	The tags did it for every tag (it was slow enough anyway)	00:50
normalperson	and it sadi it was doing do_switch and not do_update?	00:51
	said*	00:51
hharrison	The symptom was it would say do_switch....but at the end of the list of files crash with an error at git-svn line 964	00:52
	..I pasted the whole error last night	00:52
	invalid network data or somesuch	00:52
	normalperson: unfortunately now I get: Malformed network data: Malformed network data at /usr/local/bin/git-svn line 964	00:53
normalperson	hharrison: k, I'll look at it later	00:53
hharrison	thanks	00:53
normalperson	I'll let git-svn run and see if I can reproduce it	00:53
hharrison	normalperson: re-cloning or rebuilding my clone?	00:57
	→ Romster joined	00:58
cehteh	how far is 1.5.3? submodules support... to be released very soon?	01:01
hharrison	normalperson: sigh, I wish your do-switch svn-perl worked, getting tired of it pulling down the whole thing on each new branch	01:48
	Hmmm, interestingly enough, you do_switch does complete the new branch just grabbing the delta, it's the next svn commit it barfs on	01:50
	gets to:	01:50
	successfully followed parent and then the Malformed nework data error	01:51
	restarting the fetch picks p just fine though, so I'll just have to keep restarting it everytime I hit a new branch	01:52
	→ doublec joined	02:01
	→ eventualbuddha joined	02:41
eventualbuddha	i'm getting the "Network connection closed unexpectedly" problem described at http://lists.zerezo.com/git/msg431095.html. does anyone know a way to resolve this?	02:42
manveru	heya eventualbuddha :)	02:47
eventualbuddha	manveru: hola	02:48
manveru	and no... can't really help you, i'm just trying since days to convert a darcs repo :P	02:48
eventualbuddha	manveru: ah darcs. i still like darcs, but there's no darcs-svn that i know of (no, tailor doesn't count)	02:49
manveru	heh	02:50
	i'm not really interested in svn	02:50
eventualbuddha	manveru: well, i'm stuck	02:50
	manveru should stop using 'really' all the time, really	02:50
eventualbuddha	i can either use svn, svk, git-svn, or some tailor thing, but i can't abandon it because we can't change the repo	02:51
context	eventualbuddha: what are you trying to do	02:53
	eventualbuddha: i used svk a long time before git	02:53
manveru	context: ?! you here? :)	02:53
context	of course	02:54
	id recommend git over svk for svn interction	02:54
	manveru: im in your dresser	02:54
	stealing your socks	02:54
manveru	:)	02:55
	well, maybe someone of you guys can help me then	02:55
	[14:37] manveru \| i got a problem with darcs2git.py - it doesn't seem to create anything useful...	02:55
	[14:37] manveru \| i.e. i get a skeleton structure of a git repo, but no branches	02:55
context	whats up	02:55
	o :x	02:55
	ive never touched darcs	02:55
	git branch -v -a	02:56
manveru	well	02:56
	the thing is	02:56
	→ segher_ joined	02:56
manveru	it seems to do the conversion	02:56
	but all i'm left with at the end is a HUGE diff	02:56
context	maybe thats what was intended from the script :x	02:57
mugwump	eventualbuddha: try svk + git-svn	02:57
	you can convert local mirror paths	02:57
manveru	well, and an empty dir	02:57
	it does have tags though	02:57
context	manveru: do: git tag -l ; git branch -v -a	02:58
	:/	02:58
	ive never used darcs maybe i shoukld stop	02:58
manveru	hum	02:58
	that does something	02:58
	the first lists the tags	02:59
	[manveru@sigma ramaze.git]$ git branch -v -a	02:59
	* master 2c07b11 As expected, adding tests shows bugs :)	02:59
	but...	02:59
	what now?	02:59
context	heh	02:59
	is that it, just master ?	02:59
manveru	i never used git...	03:00
context	manveru: what are you trying to do :/	03:00
manveru	i try to convert a repo to git	03:00
	using the darcs2git.py script	03:00
context	and that it seems it did	03:00
	git log	03:00
manveru	uhm, yeah	03:01
	whole history there	03:01
	but where's my code?	03:01
context	git co master	03:01
	err	03:01
	git checkout master	03:01
	aliases have to be setup manually using git alias	03:01
manveru	cannot be used without a working tree?	03:01
context	your code is in the repo	03:02
	.git	03:02
manveru	it hides from me :P	03:02
context	like svn ;)	03:02
manveru	uhm	03:02
	.git?	03:02
context	ls .git	03:02
	or did you make a bare repo	03:02
manveru	no such file or directory	03:03
context	ls -a	03:03
manveru	nope	03:03
	no hidden stuff	03:03
context	what is there	03:03
	im guessing you have a bare repo	03:03
manveru	i got HEAD, branches, config, description, hooks, info, objects, refs	03:03
context	yeah thats a bare repo	03:03
	cd ..	03:03
	git clone remaze.git remaze	03:03
eventualbuddha	mugwump: the problem with that setup is that i add another step or two to committing stuff upstream. 1) git commit 2) git svn dcommit 3) svk smerge	03:04
manveru	context: you are awesomeest!	03:04
context	eventualbuddha: you can replicate from local telling it the real url	03:04
	eventualbuddha: depending on the # of revisions	03:04
	id just git svn init from the real repo	03:04
manveru	and it's freaking fast	03:04
context	manveru: ;)	03:05
manveru	(compared to darcs, that is)	03:05
context	and bazaar	03:05
manveru	i never used another SCM	03:05
	so...	03:05
	i'm kinda stuck with my comparision :)	03:05
eventualbuddha	context: hmm, interesting. but still, then i'd have the same problem	03:05
manveru	now i just have to learn the 144 commands for git-*	03:06
eventualbuddha	(the connection broken thing)	03:06
context	eventualbuddha: what ?	03:06
	just keep fetching	03:06
	git svn fetch	03:06
	or i missed something	03:06
eventualbuddha	context: http://lists.zerezo.com/git/msg431095.html	03:06
context	manveru: haha naw just learn the important ones first	03:06
manveru	how do i know what's important?	03:07
	there's a tutorial, but it's specific for the linux kernel	03:07
eventualbuddha	manveru: just try to do stuff. when you hit a wall, look it up	03:07
context	eventualbuddha: mm ive never seen that and i dcomit often :/	03:07
	manveru: read the quick intro guides in the wiki	03:08
eventualbuddha	context: i never run into this in my other project (https), but i'm getting it on my other one (svn+ssh)	03:08
context	if you have any specific questions i can help	03:08
	yeah all the projects i have are https:// :/	03:08
eventualbuddha	i wonder if i could do a fuse mount of the remote fs and then do a file:// commit...	03:09
	would that totally fubar git-svn?	03:09
context	possibly. worth a try i guess, you can always rebase/reset	03:10
eventualbuddha	context: any idea how to tell git-svn to use a different url?	03:10
context	nope	03:11
	;)	03:11
	mm i wish i could get coffee this time of niht	03:11
	→ spuk joined	03:18
eventualbuddha	hmm, didn't work. complains about not being able to get svn info	03:22
	← rephorm left	03:22
eventualbuddha	any recommended tools for taking a git patch and applying it to an svn (or svk) checkout?	03:23
cehteh	patch -p1 ?	03:27
eventualbuddha	cehteh: hmm, -p1 you say? never tried that voodoo	03:28
cehteh	i meant just normal patching	03:28
	maybe git-svn can do better .. but i dont use it much	03:29
eventualbuddha	cehteh: i just want it to put in the changes. i'll handle the svn manipulation	03:29
	cehteh uses git-svn only to checkout SVN projects since i have no svn installed :)	03:29
cehteh	what git-diff produces is a almost normal unified patch .. you can apply that with patch	03:30
	and then commit with svn	03:30
	crude workflow .. but should work .. and there are certainly better ways i dont know	03:31
eventualbuddha	cehteh: well git-svn does fine usually -- just happened to barf on this particular diff	03:31
	cehteh: and -p1 worked!	03:31
	eventualbuddha etches -p1 into his hand so he'll remember	03:31
context	eventualbuddha: git show --no-color would work	03:38
	err should work	03:38
hharrison	eventualbuddha: git diff --no-renames should produce unified diffs only	03:56
	I believe	03:57
aeruder__	there's a git-diff -p for generating patches	03:58
hharrison	I think you need --no-renames to make sure it doesn't generate the extended git syntax	04:00
manveru	context: to get a git repo over ssh... do i use git-ssh-pull or git-ssh-fetch?	04:09
context	git fetch	04:10
	or git pull	04:10
manveru	and how does the address look like?	04:10
context	host:dir	04:10
manveru	hmm	04:11
context	urls default to ssh here	04:11
	so for http://git.plastik.us i go : git clone plastik.us:git/examples	04:11
	git in my ~ is a symlink to /home/git	04:11
	where i store all git repos	04:11
manveru	yeah	04:11
context	manveru: and i just do git fetch ; git merge ; git push	04:12
	and it defaults to said origin	04:12
	manveru: i hate the git-* commands and always use the git frontend	04:12
	i havent touched 3/4's of those git-* commands	04:12
manveru	well	04:13
aeruder__	they're the same thing	04:13
manveru	they are kinda... dominant :)	04:13
aeruder__	git-blah == git blah, git-blah works better with standard tab completion ;)	04:13
context	manveru: the git command frontend calls the expanded git-* commands since some of them are builtin, and some are shell scripts	04:13
manveru	aeruder__: exactly	04:14
	i can't seem to pull it...	04:15
context	pull what	04:15
manveru	the repo i cloned before	04:15
	i want to get it on another machine	04:16
context	i populate remote repos using push -f	04:16
	git init ; git push -f url:blah	04:16
	that could be bad but meh :/	04:16
manveru	uhm	04:17
	push to get?	04:17
context	manveru: git init on the server, push on your end	04:17
	no, clone to get initially	04:17
	not pull	04:17
manveru	ah	04:17
	thanks	04:17
	that worked	04:17
context	;)	04:17
	mm i need caffeine	04:18
manveru	i need lunch :)	04:18
context	bring me something back	04:18
normalperson	hharrison: ok, I can reproduce it, but it may be a few days before I can fix it (real-life sets in)	04:18
	hharrison: but yeah, it's perfectly safe to restart git-svn there	04:18
	→ context joined	04:18
context	YEY go irssi	04:19
aeruder__	real-life sucks ;)	04:19
context	agreed	04:19
manveru	but the gfx are awesome	04:19
context	HAHAHAHA	04:22
	manveru: took me a second to get that	04:22
manveru	context: that was 3 minutes :D	04:23
aeruder__	heh	04:23
hharrison	normalperson: thanks, it's still a lot faster, even if I do have to restart occasionally	04:24
manveru	j/k :)	04:24
context	manveru: close enough	04:24
hharrison	looks like the whole gcc repo should be around 320MB packed, not bad from 8.6GB svn	04:24
manveru	time to get git on my notebook and dabble around with it :)	04:24
hharrison	normalperson: glad to hear it's safe to restart though each time	04:26
	→ Romster joined	04:26
context	manveru: what kinda notebook	04:31
manveru	subnotebook, fujitsu fmv-biblo loox t70s, google it :)	04:32
cehteh	http://www.akihabaranews.com/en/news-14026-Toshiba's+Dynabook+SS+RX1.html << just seen the annouce today .. awesome	04:35
	11h on battery, rugged, light, not too shabby cpu, ....	04:36
context	meh	04:46
	i <3 my mbp	04:46
	aeruder__ just has a regular mb, and its pretty awesome ;)	04:50
	→ meyering joined	05:03
	→ devogon joined	05:08
segher_	context: yeah, the powerbooks are way better	05:11
context	wrong	05:12
	powerbooks like like little kid toys	05:13
	→ fhobia joined	05:13
segher_	pffffrt :-) great joke	05:13
	→ dkagedal joined	05:58
	→ kanru joined	06:18
context	xmen 3 should have had nightcrawler in it	06:19
	:( so sad	06:19
manveru	context: any ideas how to do a kind of `darcs revert` in git?	06:24
	i.e. if i have deleted a file or directory, to restore them?	06:24
	→ Thumper__ joined	06:25
cehteh	manveru: git checkout - file	06:27
	-- file	06:27
	or just git checkout file .. if the name is unambigous	06:28
manveru	oh	06:28
	and for all?	06:28
	like - give me a completely original repo	06:28
cehteh	git reset --hard	06:28
manveru	ah ha	06:28
cehteh	throws away all your changes	06:29
manveru	good, thanks :)	06:29
	there are only examples for some --soft ^HEAD... which doesn't work	06:29
cehteh	urgs	06:29
	be careful with that	06:29
	git reset --hard HEAD^ throws away your last commit	06:30
manveru	hehe	06:30
cehteh	you need the reflog and some work to get it back	06:30
manveru	i've got tons of clones around	06:30
	just playing around to learn git	06:30
	the original repo is darcs anyway	06:30
hharrison	has anyone done a conversion of binutils to git?	06:31
siprbaum	manveru: cehteh: "git checkout -- file" will checkout the file as it recorded in the index. so if changed the file and did a "git add file", you will get back your changed file and not the original one. "git checkout HEAD -- file" will to the trick there.	06:35
	→ bentob0x joined	06:44
	→ etnt joined	06:56
cehteh	siprbaum: yeah .. i thought he hadnt added it yet ..	07:09
siprbaum	thought i should mention it, because this could lead to some user confusion, at least it happened to me :-))	07:11
	→ jmspeex joined	07:17
	→ ofri joined	07:20
	← dduncan left	07:39
context	manveru: how is the ole learning goin	07:41
manveru	quite well so far	07:42
	some things are a bit obscure... but that may be only me :)	07:42
context	good to hear	07:42
	nah, git does a few things rather differently than other dscm's	07:42
	i used mercurial before git	07:42
	little simpler to grasp	07:42
	but git i find more powerful	07:42
manveru	hmh	07:43
	i'm also put off that the windows version seems to be a stepchild	07:43
	i got quite some windows-users who will want to contribute	07:44
context	windows and git dont get along	07:45
	unless your doing it in cygwin i guess i dont know	07:45
	i havent touched windows in forever	07:45
manveru	likewise	07:45
context	if you want soething like git and works in windows, id have to recommend hg :/	07:46
manveru	hehe	07:46
	nah, then i rather stay with darcs for the time being	07:46
	it's not like i have to switch	07:46
context	isnt darcs like all 'patch based'	07:48
	or some crap	07:48
	→ dkagedal joined	07:53
manveru	context: yeah	08:00
	it's a bit messy and a bit slow	08:00
	but hey, it's haskell :D	08:00
context	heh	08:00
	ahh then i wont try playing with it	08:00
	its whole patches idea just sounds kinda scary	08:00
	to me anyway :/	08:00
manveru	:)	08:01
	i don't care... the only feature is that it's really simple to use	08:01
context	ehh	08:01
	heh*	08:01
	if your really looking for something new / portable try out hg	08:02
DraX	i've heard more then a few repository corruption stories with darcs	08:02
manveru	yeah	08:02
	that's why i tag/release every 100 patches	08:02
	it certainly isn't as rock-solid as git	08:03
context	;)	08:03
ofri	isn't darcs moving to git under the hood?	08:04
mugwump	darcs does one thing well and that's topic branches	08:04
	some would say ... it does them /too/ well	08:04
	mugwump plays an eiree jingle	08:04
segher_	why is that?	08:04
mugwump	well to darcs any patches which "commute" are a logical topic branch	08:05
segher_	that's insane	08:05
	i have many topic branches where the patches _don't_ commute, too	08:05
mugwump	advanced darcs users specify it, I've seen the graphviz .ps output	08:06
	in all its glory	08:06
context	ofri: looks like it	08:06
	mugwump does a GLORY!!! jingle	08:06
context	i wanna see pretty pictures	08:07
	manveru still has the jingle ringing in his ears	08:08
	segher_ → segher	08:33
jmspeex	Is it recommended to have tags that move all the time in git?	09:11
context	?	09:11
	'move all the time' ?	09:11
jmspeex	I'm thinking about something like a "works_fine" tag that I can put on the master branch	09:11
	every time I feel like things are solid, I'd move that tag so people know how to get the latest version that's likely to work well	09:12
context	jmspeex: mayabe you wanna branch kind of like git does	09:12
jmspeex	context: what do you mean?	09:12
lu_zero	jmspeex make it a branch and pull to it every changes you deem stable	09:13
context	have yourmaster, than have a maint branch	09:13
mugwump	branches are just tags that move	09:13
context	that works, and only has fixes going in	09:13
	tags dont have history	09:13
	well seperated history	09:13
	→ robfitz_ joined	09:13
context	branch spcifically induces 2 lines of development	09:13
	a tag is just a specific point in time on a single branch	09:13
lu_zero	from an user pov fetch a tag or a branch is the same	09:14
jmspeex	context: I'm not looking for a history on this, just sort of just letting people know what's the latest version that's likely to work well as in "trunk is generally stable these days"..	09:14
lu_zero	from a developer pov tracking is simpler with branches	09:14
	jmspeex as pre release tagging?	09:14
context	jmspeex: than any revision in trunk should be 'relatively stable' if your gonna say that comment	09:15
	→ chris2 joined	09:15
	lu_zero uses tags just to mark releases	09:15
jmspeex	lu_zero: Basically, I'd reset to tag to HEAD every time I'm not making/merging big changes and I've done a bit of regression testing (regression testing on Speex takes ages just for a subset of the options)	09:16
context	jmspeex: maybe you should start doing unit testing	09:17
	vs testing manually yourslef	09:17
	→ MyThought joined	09:17
Tene	context: unit tests can take a very long time to complete if they're thorough enough.	09:18
context	tene: ..	09:18
	tene: yes but they can test without someone sitting there	09:18
lu_zero	I see	09:18
jmspeex	context: I'm not testing manually, it's just that my script to test the quality takes about 15 minutes to run for a particular setting.	09:18
Tene	yes, but it's still a large investment in resources.	09:18
jmspeex	There's 8 quality settings in NB and 10 settings in WB	09:18
mugwump	well let the test update the "tested" branch when it gets a good test run	09:18
	dwmw2_gone → dwmw2	09:19
jmspeex	Now, add all the cbr/vbr/... combinations, fixed-point vs. floating point and you see that it can run for a very long time.	09:19
lu_zero	you may plug it in the pre commit hook for the tested branch	09:19
	if it fails the test it will be automatically rejected	09:20
jmspeex	lu_zero: My tests aren't fully automated yet.	09:20
lu_zero	jmspeex a full speex test takes about 2 days btw?	09:20
context	you could use multiple branches, and kick off testing on specific branches and rebase after you know it works , than merge or whatnot	09:20
jmspeex	So what's the main reason not to use tags for what I'm talking about?	09:21
mugwump	changing where tags point is normally considered antisocial	09:27
jengelh	liberal? :)	09:27
lu_zero	jmspeex changing tags is similar to hack svn to change the commits once they are pubblished	09:29
jmspeex	mugwump: OK, that was my original question. Thanks for answering	09:29
mugwump	you could have branches in sub-dirs like smoked/master	09:31
	ie, refs/heads/smoked/master	09:31
	and a daemon takes the latest refs/heads/master and smokes it. all tests pass, updates refs/heads/smoked/master	09:32
jmspeex	BTW, what happens to the history of a branch when you merge another branch in?	09:32
	Do all the changes that were in the other branch appear as history or does only one change (the big merge) appear?	09:33
	(and what about conflicts)	09:33
mugwump	this is easiest to show graphically with gitk	09:33
context	jmspeex: you have to fix conflicts before checking in	09:33
jmspeex	let's say I develop a new feature in the "experimental" branch, merge that, solve a conflict, then delete "experimental".	09:34
	(of course, checking in after the conflict resolution)	09:34
	Will the new history of master show the merge+conflict resolution as one commit or will all the commits of "experimental" be shown?	09:35
mugwump	you see both branches in the log	09:35
jmspeex	mugwump: what if I later remove the branch?	09:35
mugwump	git-branch -d otherbranch is the safe way to do this	09:36
context	jmspeex: the merge/conflicts are checkin as one checkin	09:36
	you can delete the branchh	09:36
	the history isnt lost because its now connected to the other branch	09:36
mugwump	it will only delete otherbranch if it is completely merged and hence all information in the branch is in your current branch's history	09:36
context	just make sure you merge the correct way ...	09:36
mugwump	if you merged from master to experimental, when you merge back the other way it's a fast-forward, so it's not a dire problem if you get it backwards	09:37
	in fact you might make a project rule that all branches must always be merge clean against smoked/master	09:39
context	merge clean ?	09:39
mugwump	I mean to say, "mergable"	09:39
context	heh	09:40
	isnt the cleanest way to handle that to rebase	09:40
	saying something must always be mergable is kind of odd	09:40
jmspeex	mugwump: so you'd suggest merging master into experimental, then merging back to master?	09:40
context	jmspeex: if you plan to delete experimental there is no reason to go both ways	09:41
	either: rebase exp., co master, merge exp. or co master, merge exp.	09:41
mugwump	not odd at all, it's what Linus expects	09:41
context	then delete exp.	09:41
mugwump	See the google video	09:41
context	i did	09:41
	musta missed that part :x	09:41
mugwump	when he was talking about getting other people to merge for him	09:41
context	ahh yeah	09:41
	well that makes sense .	09:41
	in linus's case i take it its common for him to have like 50 remote branches	09:42
mugwump	of course you probably wouldn't bother keeping it mergable until you had written the feature and ready to have it included	09:45
context	i need to do something :/	09:46
mugwump	yes, the question. at 34:55	09:55
context	eh	09:56
mugwump	into the google vid	09:56
context	oh	10:02
	yeah i remember which part your talking about	10:03
	→ ferdy joined	10:22
tokkee	I've cloned a repo using git 1.5.x and I was trying to clone the resulting repo using git 1.4, which does not work:	10:30
	Getting pack list for http://git.tokkee.org/collectd.git/	10:30
	error: Unable to find 0000000000000000000000000000000000000000 under http://git.tokkee.org/collectd.git/	10:30
	Cannot obtain needed object 0000000000000000000000000000000000000000	10:30
	Is there a way to work around this?	10:30
	→ anders_ joined	10:32
stni	I'm using git-svn and cannot dcommit after merging changes from a separate svn branch.	10:40
	Merge conflict during commit: Your file or directory 'build.xml' is probably out-of-date: The version resource does not correspond to the resource within the transaction. Either the requested version resource is out of date (needs to be updated), or the requested version resource is newer than the transaction root (restart the commit). at /usr/local/bin/git-svn line 405	10:40
	I tried git-svn rebase before trying to dcommit	10:41
	→ etnt joined	10:45
	→ sgrimm joined	10:49
	→ robewald\|work joined	10:54
dkagedal	how do you search for a file name in a git tree? Like a "git find"	11:01
stni	dkagedal: git-ls-files *.c	11:09
	someone that can help me with git-svn?	11:10
dkagedal	stni: thanks, but you need to prepend */ to make it work like find	11:11
stni	dkagedal: strange, i got matches in subdirs without */	11:12
	using git 1.5.2	11:12
dkagedal	git version 1.5.2.1.137.g0ad70	11:13
stni	git version 1.5.2.1.gd44c7	11:13
	dkagedal: are you using git-svn?	11:15
dkagedal	yes	11:15
	but that shouldn't affect git-ls-files	11:15
stni	can you merge between svn branches?	11:15
dkagedal	not in git	11:15
stni	ok, is it not possible?	11:16
dkagedal	svn doesn't know how to merge anything	11:16
	yet	11:16
	you have to use something like svnmerge.py	11:16
	there is no information in svn about merges	11:16
	"merge tracking" is the big feature of the next version of subversion.	11:17
stni	but i thought i could merge in git after i had cloned using git-svn clone	11:17
	actually i can merge, i just cant dcommit anything after i have merged..	11:17
dkagedal	think about it, what would you expect to happen?	11:18
	when you dcommit something, it commits to svn, and then refetches from svn and rebases your git tree to use the new commit from svn	11:18
	so your merge would be lost	11:19
	(...in time, like tears in the rain)	11:19
stni	can i merge if i create a feature branch in git, and merges that branch to both my svn branches?	11:20
dkagedal	You cannot keep any merge information when you dcommit it. So you're probably better off rebasing your feature branches on the svn branch, to make the history linear	11:21
stni	i really dont understand the rebasing stuff. Have not found a good explanation anywhere (that I understand)	11:23
dkagedal	your feature branch is based on commit A (the point where it forks off from the main branch)	11:25
	the main branch has then moved on to commit B	11:25
	So commit A is a common ancestor of both the main branch (B) and your feature branch (F)	11:25
	Now, you want to recreate the feature branch so that it is based on B instead, by adding new commits that introduce the same changes as the commits from A to F	11:26
	This will make B (and A) an ancestor of F, thus there is no fork in the history of the two branches	11:26
	ergo, a linear history	11:27
	are you with me?	11:27
stni	I think so..	11:27
dkagedal	This is called rebasing. You rebase the changes in branch F so that it is based on B instead of A.	11:27
	If the changes don't overlap with the changes introduced between A and B, the rebasing is trivial	11:28
	otherwise you might need to do some conflict resolution	11:28
	if one of your F changes is actually identical to one of the changes in A..B, that is also trivial, since the change in F can be ignored	11:29
siprbaum	this could be relevant to you guys (svn merging done inside git) http://article.gmane.org/gmane.comp.version-control.git/45668	11:29
stni	siprbaum: thanks, ill take a peek	11:30
	siprbaum: that was exactly what i was looking for. It worked great. When will it be a part of the official git?	11:53
siprbaum	i don't know. probably never. there was also a relevant thread on the git ML	11:59
	let me look it up ..	11:59
	the first messages aren't that relevant, but the end of this read is a good read: http://thread.gmane.org/gmane.comp.version-control.git/49488	12:01
	s/read/thread/	12:01
mugwump	http://git.catalyst.net.nz/gitweb?p=git.git;a=commit;h=svk-merge # WIP towards that end	12:05
	→ lcapitulino joined	12:15
	→ gitte joined	12:19
siprbaum	mugwump: hm. i dont quite understand what you are trying to do there. but t9113/svk-merge.dump seems to be missing. and t9113-svn-mergetickets.sh has no +x bit set ...	12:28
	→ jasam joined	12:30
jasam	gitte, hi	12:31
	I realized that the builtin-tag.c patch sent to the list are being discussed now	12:31
gitte	Hi jasam!	12:31
	→ cedric_ joined	12:32
gitte	I only saw a couple of replies...	12:32
	But no proper review of the patch.	12:32
jasam	corrections to enhance it, I think that they could be corrections to enhance our code too! :)	12:33
	however, no code mine is published now at all	12:33
	I thought that a good action would be release the tests that we have	12:34
gitte	Yes, that sounds quite brilliant!	12:34
jasam	first is needed the key	12:34
gitte	Your tests should have no issues, as far as I know.	12:35
	Generate your patch with --binary.	12:35
jasam	first I have to finnish some things	12:35
	I replaced the wc -l with a function like this	12:35
	the tests just show some bugs from git-tag.sh and stripspace	12:36
	so it will need changes	12:36
gitte	Yes, probably.	12:36
jasam	ups	12:36
gitte	Is it hard?	12:36
jasam	anoter problem is the current assumption that the -l recives regular expressions	12:37
	s/anoter/another/	12:37
	s/recives/receives/	12:37
	anyway, that's what git-tag.sh does	12:38
gitte	Yes, I see.	12:38
	You're right!	12:38
	I did not even check the source when I said that fnmatch was probably the right thing!	12:39
	Shame on me, and my sincere apologies.	12:39
jasam	I don't think so, at least for now	12:39
gitte	I take it that you have tests for -l with regular expressions?	12:39
jasam	I think that first everything should run like git-tag.sh, except bugs	12:39
gitte	I just had a look, and git-tag indeed passes "$@" to _grep_.	12:39
	jasam: I fully, totally agree on that.	12:40
	→ nud_ joined	12:40
gitte	That is part of the reason I am opposed to take the "other" builtin-tag.	12:40
	It is in C, but it changes behaviour at the same time.	12:40
jasam	well, I will publish in my repo another change to the tests	12:41
gitte	Good.	12:41
	And then, let's prepare a patch, adding the test script.	12:41
jasam	that is what I wanted you to see	12:41
gitte	But let's leave out the tests showing a bug in stripspace and/or git-tag.	12:42
	That patch should go in real quick.	12:42
jasam	get_tag_msg () {	12:42
	git-cat-file tag "$1" >msg &&	12:42
	sed -e '1,/^$/d' -e '/^-----BEGIN PGP SIGNATURE-----$/Q' msg	12:42
	}	12:42
	→ Tali joined	12:42
jasam	ok	12:42
gitte	Yes, I absolutely like that.	12:42
	Except for one thing...	12:43
	Instead of >msg &&, you could say \|	12:43
	If there is a failure in any program of a pipe, AFAIK the exit status of the _whole_ pipe is set to that.	12:44
jasam	then, give a non-annotated tag to get_tag_msg will return 0	12:44
gitte	So, if git-cat-file fails, so will git-cat-file ... \| sed ...	12:44
jasam	I need to test it again :(	12:44
	I'm not really sure	12:45
gitte	Yes, it will return 0.	12:45
jasam	I don't like that behaviour	12:46
gitte	But I'd rather check for BEGIN PGP SIGNATURE separately.	12:46
jasam	another function?	12:46
gitte	Another test.	12:46
	Here's another idea:	12:46
jasam	get_tag_msg annotated-tag >actual &&	12:46
	git diff expect actual	12:46
	tests are now like those	12:47
gitte	sed -n -e '1,/^$/d' -e '1,/BEGIN PGP/p'	12:47
	Prints out the message, up to and including the BEGIN line...	12:47
jasam	then I need to reuse the message directly	12:48
	(I don't really do that, always used the temporary file expect)	12:49
gitte	You can still use it as is.	12:49
	The only change that line brings in, is to _include_ the BEGIN PGP SIGNATURE line.	12:50
	The Q statement will remove it, the p statement will not remove it.	12:50
	Both remove the signature, though.	12:50
	→ jmspeex joined	12:51
jasam	so, don't I need a different function?	12:51
	I'm not sure about that english construction...	12:51
gitte	Ah, you meant get_tag_msg. Yes, that _is_ a function.	12:53
	And you don't need another function, no.	12:53
	At least from what I can tell.	12:53
jasam	so, what can I do with >msg ?	12:53
	leave it that way?	12:53
	check it twice to avoid the temporary fila?	12:54
	s/fila/file/	12:54
gitte	I'd do something like	12:58
jasam	I'm reading man bash	12:58
gitte	get_tag_msg () { git cat-file tag "$1" \| sed -n -e "1,/^$/d" -e "1,/BEGIN PGP/p" }	12:59
jasam	searching for \\|	13:00
	you find the Pipelines subsection	13:00
gitte	Yes. Basically, a "\|" between two commands will pipe the stdout of the left command into the stdin of the right command.	13:01
	So for example, "ls \| grep x" will find all files that contain an x in their name.	13:02
	Now, "x" is not very interesting. But regular expressions are.	13:02
jasam	returning the status of the last command	13:02
gitte	So if you are not content with the shell patterns to match your files, you use "ls\|grep".	13:03
	Ah yes, the status of the last command. But if a command before the last in the pipeline exits with an error, the pipeline is broken, right?	13:03
	There should be a different exit status for that, but it is still an error, I think.	13:04
	Be that as may, your output would be empty in that case, and the test case fails, just as desired.	13:04
jasam	$ git-cat-file tag lalala \| sed -n -e "1,/^$/d" -e "1,/BEGIN PGP/p"	13:05
	fatal: Not a valid object name lalala	13:05
gitte	echo $?	13:05
jasam	$ echo $?	13:05
	0	13:05
gitte	Empty output.	13:06
jasam	stderr output anyway	13:06
gitte	2> /dev/null	13:07
	(before the "\|" symbol)	13:07
jasam	the same	13:07
	is seems that you are not in UNIX now :)	13:07
gitte	git cat-file tag lalala 2> /dev/null outputs something?	13:08
	Not here...	13:08
jasam	it doesn't	13:08
	carlos@carlinux:t$ git-cat-file tag lalala 2>/dev/null carlos@carlinux:t$ echo $?	13:09
	128	13:09
gitte	So that should work.	13:10
jasam	a empty output is a valid one	13:10
	the last command in the pipeline is not the last command succeed	13:10
gitte	Yes, but what you are interested in is the test.	13:11
	And that fails with an empty output.	13:11
	Doesn't it?	13:11
jasam	what's "fail"?	13:11
	it does not return different from 0!	13:12
gitte	test_expect_success ... 'diff -u expect out' will fail.	13:12
	That's what I meant.	13:12
jasam	not always	13:13
	annotated tags with an empty message are valid	13:13
	so I did test to cover it	13:13
	→ jla joined	13:14
jasam	a call to the function to test a no-message annotated tag will return 0 if the tag doesn't exist	13:14
	and also will return 0 when the tag exists and has an empty message	13:16
	I didn't put the >msg for nothing :(	13:17
	it also wil return 0 when the tag is exists and is not an annotated one	13:19
	s/wil/will/	13:19
	uff	13:19
	tag_msg () { git cat-file tag "$1" \| sed -n -e "1,/^$/d" -e "1,/BEGIN PGP/p" }	13:21
	tag_msg () { git cat-file tag "$1" \| sed -n -e "1,/^$/d" -e "1,/BEGIN PGP/p"; }	13:21
gitte	You do not need the ";"	13:21
	And I'd test the non-empty message _first_.	13:21
jasam	$ tag_msg () { git cat-file tag "$1" \| sed -n -e "1,/^$/d" -e "1,/BEGIN PGP/p" }	13:22
	>	13:22
gitte	That way, you ensure that cat-file tag works as expected.	13:22
jasam	I don't know if there is an error	13:22
gitte	Yes, you know.	13:22
jasam	it needs the ; to terminate the command!	13:22
gitte	If you have a non-empty message, and the test for that succeeds, you know that it worked.	13:22
	Ah, because of the closing "}"?	13:23
jasam	gitte, with the ; it return inmediately	13:23
gitte	Yeah, you're right. I just tested.	13:23
	But I recommend to write it in the long form in the tests...	13:24
	→ m8t joined	13:24
gitte	I am only too lazy in IRC to use multiple lines.	13:24
m8t	hi, what is the equivalent to svn propset svn:keywords Id?	13:24
jasam	ok	13:24
	→ jmspeex joined	13:25
gitte	m8t: I don't know svn, so I cannot tell what you want to do.	13:26
Arjen	Expanding of Id keyword	13:26
jasam	gitte, the way to test a non empty message is calling to git cat-file too	13:27
m8t	gitte: replacing $Id$ in code source with up to date commit dates and more	13:27
gitte	jasam: exactly. So if it does not fail, chances are really high it still works for the empty message, right?	13:28
jasam	chances?	13:28
gitte	m8t: there is a lot about that on the mailing list. I forgot the details, so that is a better place to look for.	13:29
	But I _think_ we have it in 1.5.2	13:29
jmspeex	Why doesn't git-clone create a local branch for each of the remote granch?	13:29
	s/granch/branch/	13:29
gitte	m8t: it is in 1.5.2.1. Best is to read the release notes on how to get that behaviour.	13:30
segher	jmspeex: not all remote branches are branches you should track; some might be temporary	13:31
m8t	ah good	13:31
jla	I would like to create a patch of the difference between the index and working directory (git diff) that the patch(1) command can use. I may be creating the file now, and just not feeding it to patch correctly.	13:31
jmspeex	segher: How do I add them? Is "git checkout -b..." the only way?	13:32
jla	I'm using git 1.4.4.4 on Debian 4.1	13:32
gitte	m8t: yeah, look into Documentation/gitattributes.txt	13:32
	jasam: chances in the sense of probability...	13:32
	jasam: if you are really deeply worried about it, you have to use test_tick before every call to git-tag, and you mustn't strip the tag header then.	13:33
jasam	gitte, I told you, with that function we cannot know if a tag with no message already exists or is a non-annotated one	13:34
gitte	Yes, you're right.	13:34
jasam	s/already/doesn't/	13:34
gitte	But if you take the tag header, and not strip it with "1,/^$/d", then the result is _never_ empty.	13:34
jasam	so for those test we should use another function	13:34
	gitte, non-annotated tags don't show nothing	13:35
	in git-show they show the commit	13:36
segher	jmspeex: see man git-pull	13:36
	→ spuk- joined	13:36
m8t	gitte: I got the man under hand, thank you :)	13:37
gitte	jasam: So the only proper test is to test non-annotated-tag^{commit}, right?	13:37
jmspeex	segher: thanks	13:37
gitte	m8t: sorry, I am no native speaker, what does that mean?	13:38
jasam	gitte, I don't understand that option you wrote	13:39
jla	do I need to checkin my changes and use git format-patch, or is there a way to get patch(1) compatible patches from git diff?	13:41
segher	jla: git-diff's patches are just fine	13:43
jasam	there are many things: signed tags, annotated tags, non-annotated tags, and non-existing tags, and the two first can have an empty message, I see right a function that returns the same as git cat-file tag returns, non-zero when the tag is a non-annotated tag or does not exist	13:43
jmspeex	In case anyone's interested, "git clean -d" doesn't work	13:44
	(i.e. the -d option has no effect)	13:44
	→ zer0bug joined	13:45
jasam	gitte, I have to go for a while, see you later, is easier for the caller to include in the function another test to check for an existing tag with message, why are we trying to avoid it?	13:45
jla	segher: I've tried it plain, and with --diff-options -u & -c. When I go to the non-git tree and do patch -p1 < <path to patch made from git-diff> it rejects	13:46
gitte	jasam: I finally made up my mind. We should explicitely test for failure on "git cat-file tag unannotated-tag".	13:46
segher	it says there are rejects?	13:46
gitte	You should not even use get_tag_msg for that.	13:46
segher	that just means the tree is in a different state	13:46
gitte	jla: it would be helpful if you told us _how_ it rejects them.	13:47
m8t	gitte: I wanted to say that I am reading the manual	13:47
jasam	gitte, git cat-file shows me that the tag exists and is an annotated one, that's important for the tests, get the message is a useful side effect	13:47
gitte	I.e. was the file not found, etc.	13:47
m8t	gitte: the man under hand <-> I have the manual	13:48
jla	1 out of 1 hunk FAILED -- saving rejects to file src/logfile/cabrillo.c.rej	13:48
gitte	jasam: but if you get a tag object, that always has a tag header, right?	13:48
m8t	gitte: what native-language do you speak??	13:48
	-?	13:48
gitte	m8t: thanks!	13:48
	m8t: German.	13:48
	jla: what is in the rejected file?	13:49
m8t	french here ;)	13:49
gitte	jla: Does patch -R work?	13:49
m8t	just beneath sarrbrucken	13:49
gitte	m8t: Alors, c'est chouette!	13:49
jasam	gitte, are really lightweight tags objects?	13:49
gitte	Mmmh. Tarte flambee.	13:49
	jasam: No, not as far as I know.	13:50
m8t	:)	13:50
gitte	jasam: Really lightweight tags are just commit refs, stored in refs/tags/*	13:50
jasam	gitte, and git cat-file shows that returning error	13:50
	← zer0bug left	13:51
jasam	when you ask for the message	13:51
jla	gitte: I'll try -R, http://pastebin.ca/558696	13:51
gitte	jasam: and that's what I would test for, for lightweight tags. Not the tag message.	13:52
	jla: do you find that line in src/logfile/cabrillo.c?	13:52
	Or did you actually cd to src/logfile/?	13:53
jla	gitte: the wrong line is there. the 'tried to apply to' block is a copy from src/logfile/cabrillo.c in the upstream tar'd source. I ran patch -p1 < ../<git diff.patch> from the xlog-1.4 root.	13:55
	→ Romster joined	13:55
m8t	uh, how can I clone over ssh listening on another port than 22?	13:55
jasam	gitte, see you later, then, you could explain me how to write the different tests, how to test empty messages in annotated tags, and how to ensure that they exist at all	13:57
gitte	jasam: see you.	13:58
	m8t: git clone host.org:9899/path	13:58
jasam	and thank you very much for your help!	13:58
gitte	jla: Are you sure that your updated paste is not white space damaged?	13:58
	jasam: as always, it's my pleasure!	13:58
jla	gitte: I'm not sure. I just barely posted the updated paste http://pastebin.ca/558727	14:00
m8t	it still tries on 22 :/	14:00
gitte	jla: the patch looks wrong, because there should be a newline after "information".	14:01
	→ cortana joined	14:01
gitte	jla: Is this by chance a Mac application?	14:02
aeruder__	m8t: i usually just set up alternate ports/usernames in my .ssh/config	14:02
cortana	is it possible to tell git-cvsimport to not perform a merge after it imports new commits? I'd like to rebase my branches instead of having a load of 'cvsimport' merges cluttering up the history	14:02
gitte	jla: I _suspect_ that there is _only_ a CR, but no LF by ways of a newline...	14:02
aeruder__	Host host.org	14:02
	Port 9899	14:03
	throw that in your .ssh/config	14:03
	→ fhobia joined	14:03
aeruder__	and from then on, you can just do a ssh host.org	14:03
jla	gitte: it is on a new line when viewing the diff with less, that line messed up in paste.	14:04
m8t	ah I see, ok	14:04
gitte	cortana: -i	14:04
jla	http://pastebin.ca/558740	14:04
cortana	ah	14:04
	cryptic but short :)	14:05
	thanks!	14:05
gitte	cortana: yes, short. But it is explained in the man page ;-)	14:05
	jla: Did you try to apply with "git apply"?	14:06
	jla: wait.	14:06
jla	:)	14:06
gitte	jla: did you create the patch, and tried to apply in the _same_ directory?	14:06
	→ orospakr joined	14:07
cortana	well, i see that now that it's been explained to me :)	14:07
jla	no. I made a git tree using rsync & cvsimport, then I did the work there. Upstream doesn't know git afaik. I want to make a patch(1) compatible patch out of the work I've done. I've extracted an upstream tarball as xlog-1.4. I want to patch it	14:08
	s/know git/use git/	14:08
gitte	How did you test?	14:08
	Did you _re-rsync_ it?	14:09
jla	test? (my fix?)	14:09
gitte	Or did you use git-archive \| (cd /somewhere/else; tar xf -) to create a copy?	14:09
	jla: test the patch application.	14:09
jengelh	-xf	14:10
jla	cd xlog.git; git diff > ../git-diff.patch; cd ..; tar -xzf xlog_1.4.tar.gz; cd xlog-1.4; patch -p1 < ../git-diff.patch	14:10
gitte	jengelh: works here without the first "-", too.	14:10
	jengelh: FWIW it's the "old" style options.	14:10
	jla: That _should_ work.	14:11
	What does "git diff xlog.git xlog-1.4" show?	14:11
jla	fatal, not a git repository	14:12
	fatal: Not a git repository	14:12
gitte	git version?	14:12
jla	a little old, git version 1.4.4.4	14:12
	→ chris2 joined	14:13
gitte	Okay. Would you please check that "diff -u xlog-1.4/src/logfile/cabrillo.c xlog.git/src/logfile/cabrillo.c" does not give you _another_ patch?	14:14
	IOW you could have patches relative to xlog-1.4 in your xlog.git _already_, which make that patch not apply.	14:15
	→ kanru joined	14:16
	→ rphillips joined	14:17
jla	gitte: wow. that's so simple I can't believe I tripped over so much before you pointed it out (just doing the diff outside). yes. that is the problem. :S. sorry.	14:18
	gitte: thank you very much	14:18
	gitte: I'll do the patch test against another cvs copy	14:18
	jla was tripping over the fact that the files looked different.	14:19
jla	(patch files)	14:20
	→ jmspeex joined	14:21
jla	http://pastebin.ca/558811	14:35
gitte	Wow... it's been a while that I saw somebody say "diff -c"...	14:36
jla	:)	14:37
	maybe I'd have less trouble with diff -u	14:37
gitte	;-)	14:37
jla	it doesn't seem like the diff -c output matches up	14:37
jengelh	-c!?	14:37
gitte	mm. Not really...	14:38
jla	I'm not expert, but the @@ -157,7 +157,7 @@ line seems suspect	14:38
jengelh	no that line looks ok	14:38
	starting at 157 on the left side, context size is 7. Right side: starts at 157, context size is 7	14:38
jla	when I do diff -c by hand, it does * 147,153 **	14:38
	when I do diff -u by hand, it does @@ @@	14:38
	when I run with GIT_DIFF_OPTS=-c, it does @@ @@	14:39
	other things changed in the file, but the part I wanted to change seems the same.	14:40
	→ GyrosGeier joined	14:42
gitte	jla: I suspect that HEAD:src/logfile/cabrillo.c is different from the version you have in xlog-1.4.	14:43
jla	gitte: it is. other stuff has changed. more includes higher, so the line numbers are off, other changes much lowr	14:44
	→ thp joined	14:51
thp	i've imported a svn repository and worked on my local git repository, but the committer names are wrong (svn username instead of name+email), can i edit the commit author/committer values?	14:52
jla	thanks again.	14:57
chris2	is the git blame vs annotate war over btw?	15:03
fonseca	Yes, blame won.	15:06
chris2	and is there a version that works for several files?	15:07
foom	why should it be a war? support annotate, blame, and praise like the other tools. :)	15:07
fonseca	... well there is still a compatibility alias for annotate.	15:07
	chris2: But isn't it per-file only?	15:08
chris2	but cant i annotate a directory?	15:08
foom	how would annotate be implemented on a directory?	15:08
chris2	probably just a loop for all files. can do that myself	15:08
	→ stouset joined	15:09
fonseca	foom: There first was a perl script named git-annotate, later a C version called git-blame was added.	15:09
foom	well that's just confusing. :)	15:10
	chris2 wonders if he needs blame for his purposes at all. diff ought to be enough actually	15:10
fonseca	And to end this confusion the war began. ;)	15:10
	But the funny thing was that nobody actually seemed to care or take sides.	15:11
foom	I don't see why anybody should care. having two aliases for a command isn't such a big deal	15:12
gitte	foom: there were no aliases	15:13
	One was a perl script, the other was a C program.	15:13
	Actually, there were even more than one perl script.	15:13
foom	ah, the war was actually over which implementation should win, not the name?	15:14
gitte	I am aware of at least three different perl scripts, written by three different people.	15:14
	Exactly. That was the war.	15:14
foom	how unusually peculiar! normally wars are over trivial things like names.	15:14
chris2	hmm, i have a dir and would like to see what was changed by the last 5 commits, but such that i can identify each commit	15:16
fonseca	git whatchanged -n 5 dir?	15:19
gitte	foom: or oil.	15:19
fonseca	Altho', merges are ignored so you will only get <= 5.	15:20
chris2	i want to see diffs	15:20
gitte	chris2: or, if you want to see the diffs, too, "git log -5 -p dir/"	15:20
chris2	but all diffs together	15:21
gitte	??	15:22
chris2	something like diff --cc	15:22
m8t	bye	15:23
	← m8t left	15:23
gitte	Okay, I understand something like "for f $(git ls-files dir/); do echo $f; git blame HEAD~5.. $f; done" is something which would help you?	15:24
chris2	yeah, i guess that's what i'll use	15:24
	my needs are quite special, i didnt expect it to be there	15:25
thp	is the .git/remotes file deprecated in favor of .git/config's remote configuration options?	15:27
arw	when merging, how do i see conflicts that are yet to be resolved?	15:31
gitte	thp: yes.	15:31
	arw: use git-mergetool.	15:31
arw	ah, nice.	15:33
	default is kdiff3, omg :)	15:33
gitte	arw: change the default if you like.	15:35
arw	yea, already did git config merge.tool vimdiff :)	15:36
gitte	Uurgh.	15:36
	Masochist.	15:36
arw	well, I think the same way about people choosing kdiff :>	15:37
	but, thats all a matter of taste...	15:37
gitte	Right.	15:37
	My, I don't use mergetool.	15:37
	I use a hexeditor to resolve those conflict issues.	15:37
arw	well. _that_ is 1337 :>	15:38
	→ gitster joined	15:40
	← MyThought left	15:40
	→ kervel joined	15:41
jengelh	too leet.	15:42
kervel	hello, newbie question: i'd like to create a local "master" branch that tracks a remote "master" branch. remotely, "master" is not the active branch ("origin" is), so when i do git clone, the active branch is "origin"	15:42
	the git is made by git-cvsimport, and when i do "git branch -r" i see 3 branches: origin/origin, origin/master and origin/HEAD	15:43
	and i should'nt commit in the "origin" branch i read ...	15:43
	ah, seems i need --track	15:44
	→ robin joined	15:52
arw	how can i set more than one author for a commit?	15:56
gitte	arw: you can't.	15:57
arw	gna. i suspected that...	15:57
gitte	You can note it in the commit message, though.	15:57
cortana	wow, git-rebase knows to disappear the 'cvsimport' merge commits that i made before... magic	16:02
	→ praka joined	16:03
	→ alley_cat joined	16:04
	dwmw2 → dwmw2_gone	16:06
	→ agoode joined	16:08
	→ elehack\|work joined	16:17
	→ meyering_ joined	16:18
pasky	so, I don't get it	16:21
	I have two users that are member of a group	16:21
	the group has write access to a directory	16:21
	the write succeeds for one of the users, doesn't for the other	16:21
	but fails only by git push, if I su it works	16:21
	so what the hell is wrong?	16:22
gitte	Is the user "mapped" to somebody else?	16:22
MadCoder	has he a persistent ssh connection that he never restarted since you put him in the group ?	16:22
gitte	MadCoder: git push means it is a new connection everytime.	16:22
MadCoder	gitte: no	16:22
pasky	gitte: "mapped"?	16:22
MadCoder	absolutely not	16:22
	if he uses ControlMaster ssh connections like I do	16:23
gitte	pasky: Can you write into another directory with that user?	16:23
pasky	no persistent ssh connection	16:23
MadCoder	he likely has a ssh -f -N [host] to make connection rocking fast	16:23
	hmmm	16:23
gitte	To see what user it is written as?	16:23
pasky	gitte: yes, I guess so	16:23
gitte	pasky: Am I right that this is my mob problem?	16:23
MadCoder	pasky: which pam backend are you using ?	16:24
pasky	MadCoder: none	16:24
MadCoder	grmbl	16:24
pasky	it's bare sshd	16:24
	gitte: yes :)	16:24
	sorry, in the end couldn't look at it over the weekend	16:24
	I have no idea how did you manage to push that thing	16:24
	I mean write objects	16:24
	because I couldn't	16:25
	I mean can't	16:25
gitte	I pushed as dscho.	16:25
pasky	aha	16:25
	yes, me too	16:25
	that worked :)	16:25
gitte	Since it is written that "mob" can only be initialised by somebody else.	16:25
pasky	nod	16:25
gitte	I could only assign users after creating the repo.	16:25
	Might that have something to do with it?	16:26
thp	can i change previously-wrong imported author/commiter names in a git repository?	16:26
gitte	But I guess, it is all chmod g+s, right?	16:26
pasky	imageja:...:65762:mob,dscho	16:26
MadCoder	thp: no	16:26
pasky	this is the only line that associates dscho with the imageja project either	16:26
MadCoder	thp: you must rewrite history	16:26
gitte	thp: you can filter the branch.	16:26
pasky	(I tried swapping mob dscho on the line :)	16:26
	if I throw pasky in and push as me, it works	16:28
gitte	But mob is special, right?	16:29
	Maybe ssh does something weird.	16:29
pasky	it really isn't	16:29
thp	gitte: how am i going to do it? isn't there something like svnadmin dump that i can then edit with an editor?	16:29
pasky	I even added ssh key to it now	16:29
	still nothing	16:30
gitte	I'd try to chmod a+w the repo, and try if _that_ works.	16:30
pasky	now I hosed the whole repo.or.cz chroot :)	16:31
gitte	thp: The problem is with the merges...	16:31
	But if you look into the "next" branch of git, you will find this nifty git-filter-branch tool.	16:32
	pasky: Ouch.	16:32
	Sorry.	16:32
	I have a gift. Recently I suggested to a friend that he should do something by adding himself to a certain group.	16:33
	Alas, he _replaced_ the list of the groups with that single one, by that command I though was okay.	16:33
	As it turns out, with Ubuntu, the root user is disabled. And he was the only one in the admin group, the group which gives you sudo permissions.	16:34
	He had to call someone to actually _reboot_ the box into single user mode.	16:34
	I should learn not to give these kind of advices.	16:34
	meyering_ → meyering	16:39
arw	I have a series of commits to the linux-kernel which were written by us some months ago.	16:48
	that patch-series is somewhat ugly, therefore we would like to redo all the changes in a sensible and more structured series of patches.	16:48
	is there a standard way for doing this, or some docs about it?	16:49
	git rebase obviously needs to already have a clean series of patches	16:49
MadCoder	git rebase will rebase your patches, not split them a different way	16:49
	wha't I'd do would be to first rebase the patchset	16:50
	then look at the whole big diff, and split it again manually in a brand new branch	16:50
	thp: how many "bad" commits have you?	16:50
	thp: if there is few, you want to checkout -b at the first of them	16:51
arw	about 40...	16:51
MadCoder	rewrite the commit	16:51
	commit it again	16:51
	and rebase the old branch onto this new commit	16:51
	see git-rebase(1) for help about that	16:51
	and you'd have to do that for each bad commit	16:52
	but you should not do that if you have exported your tree	16:52
	as it rewrites history	16:52
gitte	There is this script floating around that I seem to be unable to finish.	16:52
	Sort of a rebase --interactive.	16:52
	But it has a serious flaw: it is unable to rebase anything with merges in it.	16:52
Morbus	with gitweb, is there a way to bookmark the latest version of a particular file?	16:54
	hb=HEAD?	16:54
	seems like it.	16:55
MadCoder	yes hb=HEAD	17:00
	it's even in the links in the UI	17:00
	summary \| shortlog \| log \| commit \| commitdiff \| tree	17:00
	history \| raw \| HEAD	17:00
	^^^^	17:00
	→ cmarcelo joined	17:01
Morbus	MadCoder: yeah, that's where i got that from.	17:05
	just had to click around some more ;)	17:05
	→ sgrimm joined	17:06
pasky	gitte: now it works	17:06
	gitte: I don't know why	17:07
	→ nud_ joined	17:07
gitte	pasky: thanks!	17:07
pasky	I had to update the chroot /lib to newer libc because I simply didn't have all the old libraries around anymore	17:07
gitte	Maybe you had to crash your machine to make it work? ;-)	17:07
pasky	that's the only thing I can think of that changed	17:07
	it's strange	17:07
	but well, it works :D	17:07
gitte	Could be. They say that sometimes newer versions contain bugfixes.	17:07
pasky	sorry for the mess I've made in the mob branch, btw :)	17:07
gitte	Just a rumour.	17:07
	No problem.	17:08
pasky	new fixes and new bugs :)	17:08
gitte	Tsk, tsk.	17:08
	Empty commits. There is either a cogito user, or someone knowing git-core pretty well... :-)	17:09
MadCoder	Uli never puts bugs in the libc	17:09
GyrosGeier	naah	17:09
	→ orospakr joined	17:09
MadCoder	there is only bad programmers around, that can't match his skills	17:10
	*who even	17:10
pasky	gitte: cogito user :)	17:10
jengelh	bugs?	17:10
	:p	17:10
pasky	mod:))	17:11
	I mean MadCoder :))	17:11
	(the laughter of someone who actually follows glibc bugzilla and mailing lists)	17:11
MadCoder	pasky: you too ?	17:11
	sigh	17:11
	→ r0n joined	17:12
gitte	Wasn't there a Google talk about how to deal with difficult people?	17:12
MadCoder	gitte: Uli is not difficult	17:12
	jengelh nods	17:12
MadCoder	it's worse in any ways	17:13
	GyrosGeier cares about the ARM and m68k ports	17:13
GyrosGeier	Uli doesn't.	17:13
MadCoder	gitte: see http://sourceware.org/bugzilla/show_bug.cgi?id=4428 for example	17:13
	and sigh in despair	17:13
pasky	yes, Uli can't be difficult	17:13
	Uli is rock-solid and impossible :)	17:14
MadCoder	it's not his fault if other programmers are morons that can't read POSIX properly	17:14
gitte	Enter Git... and ... fork!	17:15
jengelh	granted, the manpage does not print "OBSOLETE" in red	17:15
	→ lyakh joined	17:15
pasky	we already have glibc in git :)	17:15
MadCoder	pasky: really ? where where where ?	17:15
	git-cvsimport on the libc explodes	17:15
gitte	klibc.	17:15
MadCoder	oh	17:16
pasky	just register a fork at repo.or.cz and it's all done! glibc forked! revolt! then start fixing the ugly nptl bugs and come back after a week... :)	17:16
gitte	... and we'd all love you.	17:16
	I'd buy you dinner.	17:16
pasky	http://repo.or.cz/w/glibc-cvs.git	17:16
gitte	Nah, I'd _cook_ you one.	17:16
pasky	I should rename it just to glibc.git maybe	17:16
	gitte: which one is better? (for me)	17:16
gitte	Probably.	17:17
MadCoder	oh my he's really touching one file at a time on purpose ? /o\	17:17
	pasky: that's really good to know	17:17
	pasky: is it an all time clone, or is there a graft for older versions ?	17:18
pasky	it is all time	17:18
	updated nightly	17:18
	MadCoder launches a clone immediately	17:18
MadCoder	pasky: well I can afford the update myself	17:18
pasky	not if you don't have the cvsps cache I think	17:19
MadCoder	it's just that after 4 hours and swapping to death, I was still somewhere in 1994 iirc	17:19
	oh	17:19
	crap	17:19
gitte	Last time I tested, you could git-cvsimport, and it was still a fast-forward, if upstream git-cvsimported, too.	17:19
	My QEmu import was different from Jens Axboe's, though.	17:19
MadCoder	git clone git://repo.or.cz/w/glibc-cvs.git glibc-cvs	17:20
	Initialized empty Git repository in /home/madcoder/dev/glibc-cvs/.git/	17:20
	fatal: The remote end hung up unexpectedly	17:20
	fetch-pack from 'git://repo.or.cz/w/glibc-cvs.git' failed.	17:20
	bleh	17:20
	mean mean mean repo.or.cz	17:20
gitte	w/?	17:20
	How about using the correct URL ;-)	17:20
MadCoder	ahem I copied the gitweb url	17:21
	MadCoder hides hides hides	17:21
	→ hharrison joined	17:21
gitte	No, the gitweb url is http://, not git:// ;-)	17:21
MadCoder	yes I fixed that	17:21
	well, "fixed"	17:21
gitte	Still resolving...	17:24
	But that means it's almost there, right?	17:24
	pasky: how about "ln -s / /w"?	17:24
MadCoder	pasky: how did you registered the import btw ?	17:25
	is it possible for any repo.or.cz user to do so ?	17:25
gitte	MadCoder: he's the admin, that's how he did it.	17:25
	MadCoder: mail pasky@repo -s Please,please,please	17:25
MadCoder	heh, riight	17:26
	that's cheating	17:26
pasky	gitte: yes thought about it	17:31
	MadCoder: nope it isn't possible for anyone, just for me :)	17:31
	← vlad_ left	17:32
pasky	gitte: done	17:32
gitte	pasky: Thanks.	17:33
hharrison	Currently what is the best option to transition a cvs repo to git	17:34
	?	17:34
cortana	git-cvsimport?	17:34
hharrison	How does it compare to fromcvs?	17:35
	Or parsecvs?	17:35
context	woo	17:45
	DirectFB is using git now. i didnt know that	17:45
	→ _ron joined	17:54
context	hharrison: you could try all 3 and see which result you like best ...	17:55
	hharrison: its your code. pick what you like	17:55
hharrison	I'm really just interested in minimum conversion time	17:56
	Just finishing a gcc svn import, had a request for binutils/gdb etc to help them evaluate	17:56
	Who knows it they'll switch, but I'll try to put git's best face forward	17:58
gitte	hharrison: you could try git-svn on the svn import ;-)	17:59
hharrison	gitte: Where's the svn import at, or do you mean cvs2svn first and then git-svn?	17:59
	I like git-svn a lot, a very well made tool	18:00
gitte	The latter.	18:00
	I am not aware of any svn import.	18:00
hharrison	gitte: I suppose I was a bit optimistic ;-)	18:00
context	id imagine cvs->git would be faster than cvs->svn->git	18:01
hpa	git-cvsimport is definitely the first thing to try.	18:01
context	hmm why was i thinking git's repo was 25M :/	18:01
hpa	If it'll work depends largely on how screwed up your cvs repo is	18:01
	However, since it's based on cvsps and patches it's not ideal.	18:02
	It gets very easily confused by binary files in particular.	18:02
hharrison	hpa: no idea on the state of binutils cvs, I'm an interested outsider	18:02
	hpa: so git-cvsimport isn't based on spearce's fastimport?	18:03
hpa	I don't believe so.	18:04
jbowes	it's not	18:04
gitster	predates it for at least by 18 months ;-)	18:05
hharrison	gitster: heard any success/failure reports for fromcvs?	18:05
	I believe it is fastimport based	18:05
	→ _ron_ joined	18:06
gitster	sorry never used it. I do not heavily interact with anything in CVS/SVN. I really should but I do not have a real need and time is short...	18:06
gitte	hharrison: I never used it. Partly because it is written in Ruby, and I was afraid I'd encounter a bug I could not fix.	18:06
	But I see corecode is here. He's the fromcvs man.	18:07
hharrison	gitster: I'm actively working on some cvs/svn imports, any pointers to a 'best practices' type document	18:07
gitster	By 'need', other than 'it would really help improving git if I did so', is what I mean.	18:07
hharrison	If not, I'll certainly try to cotribute based on my experiences	18:07
gitte	Please, do.	18:07
gitster	svn, the one by mugwump is rumored to be the canonical one for git-svn. For cvs we have cvs-migration document that is being integrated into the user manual.	18:07
hharrison	gitte: I speak ruby	18:07
gitte	AFAIK fromcvs is relatively fast.	18:08
	But I don't know if you need the RCS files. With parsecvs you definitely do.	18:08
hharrison	gitte: That's what I liked about it	18:08
corecode	yah	18:08
	i am here	18:08
gitte	Hey, Mr fromcvs.	18:08
corecode	alo!	18:08
gitte	Here is a potential client for you:	18:08
	may I introduce... hharrison.	18:09
corecode	helloooo	18:09
hharrison	corecode: what did you base it on? cvs2svn?	18:09
corecode	no	18:09
	rewrite from scratch	18:09
	techniques from svn are not necessarily applicable	18:09
hharrison	YOu wouldn't happen to have run it on binutils already?	18:09
	;-)	18:09
corecode	no	18:10
	you?	18:10
hharrison	Looks like I get the priviledge then	18:10
corecode	have fun	18:10
	please report bugs	18:10
hharrison	please have patience	18:10
corecode	should run fairly fast	18:11
hharrison	From the limited googling I've done, that's the impression I had	18:11
corecode	it won't convert tags though	18:11
hharrison	I've noticed a real lack of 'best-practices' type documents for git around, maybe I'l have to work on that	18:11
	corecode: how much work needed to bring the tags in?	18:12
corecode	there is no best practise, people are using it differently	18:12
	forget it	18:12
	tags in cvs are a bitch	18:12
	maybe linear tags could be rather easy	18:12
	and just drop everything else	18:13
hharrison	I'm not a cvs user	18:13
corecode	uhm?	18:13
hharrison	Actaully the only scm I've ever used is git	18:13
	Before that it was always tarball snapshots and ordered patches	18:13
corecode	yuck	18:13
hharrison	Small group of devs, slow rate of change, engineering modelling software	18:14
	cvs just got in the way the one time we tried	18:14
	But I'll get back to you later in the week when I have some time to tackle binutils	18:15
	corecode: did you ever talk with cworth who I think was looking at adapting the cvs2svn program to output to git instead?	18:16
	→ kaktuspalme joined	18:16
kaktuspalme	hi	18:16
corecode	no	18:16
	i'm pretty happy with my converter	18:16
hharrison	ok	18:16
	corecode: out of curiousity, what was your motivation to write it, was it existing to another backend, or totally from scratch?	18:18
corecode	uhm?	18:19
	i wrote several other cvs tools before	18:20
	and the goal was to convert a cvs repo I use	18:20
	→ MyThought joined	18:22
foom	cvs2svn is the only cvs2anything tool i've seen which actually works.	18:23
	but, just my experience. :)	18:23
corecode	it is not cvs2anything	18:23
	tailor is cvs2anything, yet not very good	18:23
foom	I should've said cvs2something	18:24
	→ tcoppi joined	18:25
corecode	well, mine works as well	18:26
	and fast	18:26
	and incremental	18:26
hharrison	oh, yours is incremental as well?	18:27
gitte	Okay, shootout. :pserver:anoncvs@sourceware.org:/cvs/src binutils	18:27
	fromcvs against cvsimport.	18:28
hharrison	I'll be busy until later in the week, but unless someone beats me to it, I'll take fromcvs	18:28
pasky	gitte: removing it again, gitweb hates it	18:30
	/srv/git/w is a recursive symbolic link at /usr/share/perl/5.8/File/Find.pm line 549.	18:30
gitte	Oh sh*t.	18:32
	I really should hold my suggestions, shouldn't I?	18:32
	corecode: any idea how to get at the RCS files when all you have is above mentioned pserver url?	18:36
corecode	mail the hostmaster	18:36
	maybe you could spider them	18:37
	but it would be unbelievably slow	18:37
	→ jlh joined	18:42
context	mm i get this trying to do git-cvsimport:	18:43
	AuthReply: cvs [pserver aborted]: descramble: unknown scrambling method	18:43
	actually	18:47
	where do i get cvsps	18:47
corecode	use fromcvs	18:49
	it's better anyways	18:49
gitte	It seems that all documents on savannah.gnu.org suggest that there should be a way to rsync the cvsroot, but the URL is wrong.	18:49
	corecode: I'd like to see this underlined by some numbers.	18:49
	I haven't seen _any_ numbers on fromcvs.	18:49
corecode	how do you quantify quality	18:49
hharrison	My gcc import just passed the million object mark, getting close to the end	18:49
gitte	By talk?	18:49
corecode	well, don't use it then	18:50
	i don't care	18:50
gitte	Hey, I said I would _like_ to see this underlined.	18:50
hharrison	The 20:1 svn:git ratio seems to be holding	18:50
context	corecode: url for fromcvs	18:50
corecode	gitte: well, still the question holds: how do you quantify quality	18:50
gitte	http://ww2.fs.ei.tum.de/~corecode/hg/fromcvs/	18:51
context	thnx	18:51
hharrison	corecode: hg/fromcvs ?	18:51
gitte	And I _think_ there should be a cvsps.git on repo.or.cz	18:51
corecode	hharrison: yes	18:52
gitte	Yep. http://repo.or.cz/w/cvsps-yd.git	18:52
hharrison	Does fromcvs output to hg as well then?	18:52
context	fromcvs->hg->git ?	18:52
corecode	yes	18:53
gitte	corecode: I don't quantify quality. Of course that is the answer you wanted.	18:53
corecode	fromcvs does multiple destinations	18:53
context	kk	18:53
hharrison	corecode: what others?	18:53
gitte	But I did not say that I want to assess some obscure kind of quality.	18:53
corecode	gitte: no, i'd like to see some numbers as well	18:53
	hharrison: a quick-search database	18:53
context	i dont have cvsroot	18:53
	:/	18:53
corecode	hharrison: but writing other destinations is fairly simple	18:53
	cvsroot?	18:53
context	err nm	18:53
corecode	ah	18:53
context	i dont use cvs. im a dork	18:54
jengelh	not using cvs is a good thing if you ask linus	18:54
hharrison	Makes me kind of curious how well fromcvs would work on the unified fedora cvs	18:54
	Could probably drop in replace with git-cvsserver	18:55
gitte	Umm.	18:55
	I did that once, long time ago.	18:55
	It _sorta_ worked.	18:55
hharrison	What kind of issues did you run into?	18:55
gitte	IIRC one revision was off, since there was some cvsps fsckup.	18:55
hharrison	ahh, you used git-cvsimport?	18:56
gitte	But do try, by all means.	18:56
hharrison	How big are the ,v files for fedora?	18:56
gitte	git-cvsserver became ways better since then, and so did cvsimport.	18:56
	(Can't tell for the other cvs converters; I often cannot get at the rcs files other than via :pserver)	18:57
hharrison	Yeah, it's going to be slow for any converter if it can't get directly at the ,v I suspect	18:57
	→ _ron joined	18:58
gitte	Now, if only I could change the world, so that my tools work.	18:59
	And not the other way round.	18:59
	gitte sighs	18:59
	→ hein joined	19:00
	hein → Sho_	19:03
kaktuspalme	how can i convert a folder to a branch?	19:23
	is this possible?	19:23
	→ ofri joined	19:23
gitte	everything's possible with git.	19:24
kaktuspalme	:)	19:24
gitte	Do you already have a repository?	19:24
kaktuspalme	jep	19:24
	yes	19:24
gitte	You want to have the current state of the folder as an initial revision?	19:25
	Or do you want to branch _with_ the state in the working directory?	19:25
kaktuspalme	in the repository i have a folder configparser and i want that this folder is a new branch, sorry for my bad english	19:26
	ive seen on kernel.org everey folder has a new repository	19:27
gitte	No, not necessarily.	19:27
	But this would be the easiest for you:	19:27
	cd folder/ && git init && git add . && git commit && cd .. && git fetch folder/.git/ master:the-new-name-for-that-branch	19:28
kaktuspalme	hmm, but its only a little subpart from the whole project so a new repository is bloated	19:28
gitte	You don't need to fetch it if you want to keep it in a separate repo anyway.	19:28
kaktuspalme	hmm, ok i think i make a new branch and add int his branch a folder configparser, thats not so nize but it works	19:30
gitte	I think I misunderstood you, then.	19:30
kaktuspalme	is it possible that a folder can be a branch only folder not the whole thing aroung the folder	19:31
	?	19:31
	thx for the help gitte :)	19:32
	gitte, can you speak german?	19:32
	→ MorbusIff joined	19:33
MorbusIff	has anyone built git on a Mac OS X Intel box? I compiled it just fine on 10.4 PPC, but doing the same on an Intel box, with the latest Xcode gives me a configure: error: C compiler cannot create executables	19:34
robin	check config.log	19:34
	it should contain more information on why it failed	19:35
MorbusIff	yeah, i had pOked in there, but nothing more obvious than the above had stood out. is there anything specific i should be looking for?	19:35
	hrm. well, there are more errors in here, but not anything i undestand.	19:36
	configure:1570: cc conftest.c >&5	19:36
	/usr/bin/ld: can't locate file for: -lcrt1.o	19:36
	is the nearest to the error i'mseeing.	19:37
lcapitulino	MorbusIff: do you have the libc-devel package installed?	19:41
	MorbusIff: most distros have one	19:41
MorbusIff	lcapitulino: well, that's a hard thing to answer.	19:42
	i installed apple's xcode, which includes a number of the unix developer thingie things.	19:42
	i chose to install /only/ gcc 4.x.	19:42
lcapitulino	oh	19:42
MorbusIff	would i get libc-devel with gcc 3.?	19:42
	that was an option i chose not to include.	19:42
lcapitulino	you need a libc-devel package	19:43
	check if you have that	19:43
gitte	lcapitulino: he's talking about MacOSX.	19:43
lcapitulino	oh	19:43
	not sure how MacOSX call things, but something like 'crt1' is needed anyway	19:44
	it can have other name, or can be linked differently	19:44
	but you need it	19:44
MorbusIff	yeah, i'm trying to narrow down if it may not have come with the gcc 4 install.	19:44
robin	I have a vage recollection that on macosx installing gcc did NOT bring in development packages	19:44
MorbusIff	i don't recall if i installed both gcc 3 and 4 on the other machine.	19:44
	→ lyakh joined	19:45
robin	look at what packages you can install and you will probably see it	19:45
MorbusIff	well, save for a bunch of os x specific SDKs, the only unix-y things they listed was gcc 3.? and gcc 4.0	19:45
	a bunch of other unix bins were part of the generic Developer Tools package, whcih I did install.	19:46
	(so now i have cvs and blah blah blah)	19:46
robin	I dont' think it had a very unixy name.	19:46
	"development" blah blah something	19:46
	it was more than a year ago I was on the mac, but I was suprised gcc did not include such elementary things as a runtime	19:47
MorbusIff	hrm.	19:48
	i /do/ have things like:	19:48
	/usr/lib/gcc/darwin/3.3/crt2.o	19:48
	/usr/lib/gcc/i686-apple-darwin8/4.0.1/crt2.o	19:48
	but, no crt.0	19:48
	crt.o	19:48
lcapitulino	crt.0 comes from libc, not from gcc I think	19:49
MorbusIff	oddly, i just did the same search on the other box, and there was no crt.o there either.	19:50
	er, crt1.o	19:50
	http://privatepaste.com/12TQXRhh0e	19:52
	is the cc related part of the config.log.	19:52
	→ weitzman joined	19:55
lcapitulino	hmm	19:58
	MorbusIff will reinstall xcode (after redownloading it again, ugh) and add more options ;)	19:59
lcapitulino	maybe this is a stupid question, but in svn if I do 'svn cp file file1' I'll be able to see in file1's history, that this operations has ocurred somewhere in time	19:59
	how do I do that in git?	19:59
MorbusIff	git tracks content, not files.	20:00
lcapitulino	MorbusIff: sure, and the contents are the same :)	20:01
Tali	lcapitulino: just use cp	20:01
	lcapitulino: you can see it with git log --stat -C	20:02
lcapitulino	Tali: I thought about doing so, lets see	20:02
gitte	I think you also needs --find-copies-harder.	20:02
Tali	gitte: you are right, at least if the origina is not modified in the same commit	20:02
	lcapitulino testing	20:04
gitster	more interesting (because SVN would never ever be able to do this) is to do "cat file1 file2 >file3" (file1 and file2 are tracked files), then "git add file3 && git commit", and run "git blame -C -C -f -n file3".	20:08
	→ ceco joined	20:10
thp	MorbusIff: don't you have the osx install cds? they also include xcode tools, don't they?	20:10
MorbusIff	they do, yeah, but old versions.	20:11
	2.0, I think 2.4 is avail. now.	20:11
ceco	hi. where does one report possible bugs with git ?	20:11
thp	i see	20:12
gitte	ceco: the mailing list.	20:12
gitster	see title of this channel	20:12
gitte	[email@hidden.address]	20:12
ceco	gitte: thanks. is there a bugzilla or something like that where I can search before I post ?	20:13
gitte	There is gmane.	20:13
gitster	we dont have that many bugs ;-)	20:13
gitte	:-)	20:13
ceco	it is not git-exactly. missing files after git-svnimport	20:14
gitte	But soon we will have a bugtracker, it seems!	20:14
	ceco: Ah, have you tried git-svn instead?	20:14
MorbusIff	eh? http://developer.apple.com/qa/qa2001/qa1118.html	20:14
ceco	gitte: I needed to import the whole repository. Full transsition from svn to git.	20:15
gitte	ceco: that is possible with git-svn, too.	20:15
ceco	gitte: I ended up doing it manually, but I thought I shoudl report the possible bug	20:15
gitte	only that git-svn is well maintained, whereas svnimport is almost abandoned.	20:15
	Yes, please do so nevertheless.	20:15
	So that next time somebody searches the list, she has a bigger chance to see that.	20:15
	meyering → jim-away	20:16
ceco	gitte: I see. I will make a few tests with git-svn and post to the list. thanks !	20:16
gitte	My pleasure.	20:17
lcapitulino	gitte: hmm, actually I'd to be able to get the log before the copy	20:18
	for example: cp file file1; git add file1; git commit; git log file1	20:18
	then I'd see 'file's log	20:19
	did you get it?	20:19
gitte	Yes.	20:19
	git diff -C --find-copies-harder HEAD	20:19
robin	log, not diff	20:19
gitte	Sorry.	20:20
robin	git doesn't do that	20:20
gitte	I thought you wanted to see the message "copied" before actually committing.	20:20
	→ sta joined	20:20
gitte	So, you want to see the log message, and _after_ that a message that the file was copied?	20:20
robin	like git show HEAD file;git show HEAD^ file	20:21
	etc etc	20:21
	oops	20:22
gitte	robin: yes, that's what I wanted to show. Only I forgot the "--stat".	20:22
lcapitulino	gitte: I want to be able to see file's log before the copy doing 'git log file1' and also the 'copied' message	20:22
robin	like git show HEAD file1;git show HEAD^ file;git show HEAD^^ file	20:22
lcapitulino	interesting, looks like git-blame is able to show all the past commits (before the copy)	20:22
gitster	It is not limited to the copy.	20:22
	'git blame' tracks contents, not file moves or copies.	20:23
gitte	Try this: cp file1 file2; git add file2; git diff -C --find-copies-harder --stat --diff-filter=A HEAD	20:23
gitster	have you tried the earlier example I gave you?	20:23
lcapitulino	gitster: will try it now	20:23
	both	20:23
gitster	"cat file1 file2 >file3; git add file3; git commit; git blame -C -C file3"	20:23
foom	it'd be nice, perhaps, if you could "find copies harder" once, and cache that info so that in the future you didn't have to find them harder. :)	20:24
gitster	More interesting, realistic, and useful in practice is to move a function or two from file1 and file2 to create new file file3. IOW, not just "cat file1 file2 >file3". Move the contents while making that new file3 and recording it in a commit. blame will follow that just fine.	20:25
lcapitulino	yes	20:26
gitster	And that all is because git does not care about file boundary. It tracks contents.	20:26
lcapitulino	now I understand	20:26
	thanks a lot for the help guys	20:26
MorbusIff	ah ha.	20:27
	ok. got it going now.	20:27
	installed "BSD SDK" "X11 SDK" and "Mac OS X 10.4 (Universal) SDK"	20:27
	and now the git configure is going dandily.	20:28
	Thumper__ → Thumper_	20:28
	gitte thinks it was the BSD SDK	20:30
MorbusIff	oddly, i did not see a crt1.o in there, but there /was/ one in the 10.4 SDK.	20:30
	everything's dandy now - install finished and confirmed.	20:31
	MorbusIff plugs laptop in and makes supper for daughter.	20:31
	→ fultilt joined	20:38
	→ DroNe^ joined	20:39
lcapitulino	gitster: BTW, how does git do that? :)	20:49
	that's amazing	20:51
robin	lcapitulino: hard work!	20:53
	→ sgrimm joined	20:58
	→ dduncan joined	20:58
	→ lyakh joined	21:00
	DroNe^ → DroNe_Away	21:00
	gitster says "by tracking contents" in hollow voice...	21:00
	→ gitte joined	21:00
	→ mneisen joined	21:01
	DroNe_Away → droNe^	21:06
	→ nashdj joined	21:31
	→ tcoppi joined	21:37
	→ strangy joined	21:50
	→ doublec joined	21:50
	→ orospakr joined	21:58
robin	I wonder if I can start using my dogfood (git index implementation for eclipse)	22:00
	s/using/eating/	22:00
	→ sgrimm_ joined	22:04
	→ spearce joined	22:04
spearce	hmmph. gitster merge git-gui.git's master i see.	22:06
	and the merge was buggy /me thinks.	22:06
	yup. bug in subtree merge strategy i think.	22:09
gitte	How so?	22:10
spearce	git diff -p 32af629 master:git-gui	22:10
	now 32af629 is my git-gui master; the second is obviously the subtree where its "mounted" in git.git. yes?	22:10
	there should not be a difference. yet there is.	22:11
gitte	3 empty lines?	22:11
spearce	i think the difference came in today during the merge. i noticed it earlier today when i did the subtree merge of git-gui into my own local build of git.git.	22:11
	yea	22:11
	the tree not matching means git-gui's version generator cannot grab the tag properly, so git-describe doesn't work. arrgh.	22:12
gitte	Maybe they were stripped on purpose?	22:12
	Both files had them as trailing empty lines...	22:12
spearce	i doubt it. i was able to produce the same problem today when i just ran `git pull -s subtree ../git-gui master`	22:12
	i meant to look at it tonight.	22:12
gitte	Back in good ole' free Europe, it is already tonight. Quite so. :-)	22:13
spearce	i had HEAD = 287d0bdf2bc319012a389d2b82fb19e92046bf35 (aka next); git pull -s subtree ../git-gui 32af629; and that produced the blank line difference. there wasn't a difference before. sigh	22:13
	i'm happy to hear you made it back home safely.	22:13
gitte	I never was happy with that version generating stuff...	22:13
spearce	git-gui's? or just git's in general?	22:14
gitte	Safely, yes. With an 8.5 hours unplanned stay on a lovely airport.	22:14
	in general.	22:14
	→ jmspeex joined	22:15
	← sta left	22:24
	→ GyrosGeier joined	22:35
gitster	spearce: isn't the difference from the earlier "War on whitespace"?	22:45
spearce	is that what it is?	22:46
	dammit, who applied a git-gui patch in a git-gui subdirectory?	22:46
gitster	Me ;-)	22:46
spearce	gah. you broke my version generator.	22:46
gitte	a6080a0a44d5ead84db3dabbbc80e82df838533d	22:46
gitster	Yeah, should have been a bit more careful.	22:46
gitte	spearce: why don't you just apply the whitespace fix yourself?	22:47
	Then, the trees should match again.	22:47
spearce	yes, apparently i have to.	22:47
gitte	Is that a bad thing?	22:47
	You make it sound like one.	22:47
spearce	no, its just annoying that those git-gui patches didn't come through my master git-gui tree.	22:47
gitte	Maybe you have to -s subtree merge master?	22:48
	:-)	22:48
spearce	no, because then git-gui inherits all of git.git's history. which i don't want it to do.	22:48
gitster	That would probably work, but I plan to ditch git-gui from git.git, after 1.6.0 or so when everybody who wants to build from the source has recent enough git with superproject support, and point at it from git.git.	22:48
spearce	right. i'm expecting that.	22:48
gitster	So merging git.git into git-gui would not be such a good idea.	22:49
gitte	Ah, why not? There's always git-filter-branch!	22:49
mugwump	gitster: nice one with that git-log patch yesterday	22:49
gitte	Just kidding.	22:49
mugwump	I spent a bit trying something similar passing filehandles into the function and didn't get far	22:50
gitster	I am still struggling with the mess that is pretty_print_commit().	22:50
spearce	its not pretty, is it? ;-)	22:50
jasam	gitte, there is a new change in the tests for builtin-tag.c in my repo	22:50
gitte	Okay. Will go and have a look at it.	22:52
jasam	thanks	22:52
robin	spearce: do you know if it's possible to get the short commit id into Eclipse's export (instead of .qualifier)?	22:53
spearce	robin: i think it might be messy, you have to edit the MANIFEST.MF file before you export. a simple script would do the trick, but you have to run it before you kick the export off.	22:53
	unless you can control how .qualifier behaves. which i doubt you can, as they are so cvs centric.	22:54
robin	time to fix ant script maybe	22:54
spearce	heh. yea.	22:55
	gitte loves doing git-branch -M on the current branch	22:55
robin	time to eat my own dog food and use eclipse to add new files to the index :D	22:56
spearce	:)	22:56
robin	scary, isn't it	22:56
gitte	Last week, somebody asked me what the status of the Eclipse Git plugin is...	22:56
spearce	it exists? ;-)	22:56
robin	it is "changing"	22:56
gitte	Now, I can say that at least one main developer uses it...	22:56
robin	silence please :)	22:59
	yes!	23:00
	Is David Watson here?	23:00
	I need that commit dialog now	23:00
	or 'want', at least	23:00
spearce	i don't know if he's an irc guy. but he's making an uber-cool dialog.	23:02
	→ dash_ joined	23:03
robin	it won't even let me fall asleep on that 20k file project	23:10
	just slow enough to let me see it is actually doing something	23:11
spearce	well sleeping and getting bored are two different times, aren't they? lately i get bored on simple merges in git, because everything is so damn fast... ;-)	23:11
	→ segher_ joined	23:11
robin	you can take a look at my pu branch	23:12
	I'll take a look at that pillow of mine	23:12
spearce	hah! thanks.	23:12
robin	good night and good luck	23:14
	→ Ingmar^ joined	23:18
	→ jmspeex joined	23:19
Ingmar^	how can I just download the MASTER instead of the whole tree from a remote git repo ?	23:22
spearce	you mean just the master branch and its history (and avoid all of the other branches), or just the latest version of the master branch?	23:23
	→ dash_ joined	23:23
Ingmar^	spearce: just the latest version, just like if it was a release tarball	23:23
spearce	use git-archive against the remote system. if the remote system is running git-daemon it knows how to send tarballs back to git-archive client.	23:24
Ingmar^	ingmar@indigo:~/repository/kernel$ git archive --format=tar --remote=git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-dev.git --prefix=linux-2.6.22-rc4-wifi/ master \| gzip >linux-2.6.22-rc4-wifi.tar.gz	23:24
	fatal: The remote end hung up unexpectedly	23:24
	should something like that work then ?	23:25
gitte	Probably it is forbidden, since it is an expensive operation.	23:25
spearce	yea. sounds like kernel.org doesn't allow it.	23:25
	→ plexq joined	23:25
Ingmar^	right, shouldn've thought of that	23:25
	so the only other way is git-clone, then do it locally ?	23:26
spearce	yes, though you may be able to use the shallow clone feature, assuming kernel.org supports that...	23:26
Ingmar^	spearce, gitte: thank you very much :)	23:27
	→ Ramune joined	23:31
	→ weitzman joined	23:47

Logs Search ←Prev date Next date→

Channels Documentation