IRCloggy #git 2007-10-03

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-10-03
michael__	(1) Solved; this bastards had a bad login script.	00:01
robinr	no, it commits all changes in one go	00:01
michael__	That hasn't been my experience	00:01
	For instance,	00:01
robinr	old version?	00:01
michael__	maybe so	00:01
	Do you have un/stable?	00:02
aeruder	git --version ?	00:02
michael__	git version 1.5.3.2	00:02
aeruder	that's pretty neww	00:02
michael__	That's pretty recent, no?	00:02
	yeah	00:02
aeruder	should be new enough anyway	00:02
michael__	So I had like 60 git commits,	00:02
robinr	yes, more than enough for cvexportcommt	00:02
michael__	and the only way to get them in cvs was to do them one at a time, one after the other	00:02
robinr	sry, I misread.	00:03
	I read "one file"	00:03
	you are right it takes on at a time	00:03
michael__	indeed	00:03
robinr	(set -e;for i in $(git rev-list HEAD~60..HEAD);do git-cvsexportcommit -c $i;done)	00:04
	but you may prefer a safer way	00:04
	→ jwb joined	00:05
michael__	what's set -e?	00:05
robinr	and do them one at a time. it only takes a few seconds per commit anyway	00:05
	that's stop on error	00:05
michael__	Well, not when you have to login it doesn't!	00:05
robinr	slow login?	00:05
michael__	I thought it would stop on error anyway	00:05
	neat though	00:05
	VERY slow	00:06
	I would much rather just be able to patch everything quickly then	00:06
robinr	you should look at why. you may have some DNS configuration problem.	00:06
michael__	and then do one commit	00:06
	Well, I have to put in my password anyway for each; there's not a way for me to setup certificates.	00:07
robinr	make a squash merge and send it to cvsexportcommit	00:07
	ssh-agent?	00:08
michael__	neat	00:09
	I'll have to try that sometime	00:09
robinr	I recall something about slow logins (in our case) having to do with non-working reverse DNS lookup	00:09
aeruder	yea, reversedns can take a long time	00:09
	(to fail)	00:09
michael__	I'm afraid I can't see the virtue of a squash merge	00:10
robinr	you wanted commit everything at once	00:10
michael__	yes	00:10
aeruder	man, squash merge throws so much away :-/	00:10
robinr	a squash merge would bolt all your 60 commits into one, which you'd send to cvs	00:10
michael__	Well, it's either time with cvsexport or its information	00:11
	I'll throw out the info	00:11
	My life is ending soon	00:11
robinr	ah, fix the dns	00:11
	you get annoyed with those slow logins after this too	00:11
michael__	Well... Don't get me wrong. I'd still have the git history, but I need to update the cvs repo	00:11
Mikachu	try starting nscd?	00:11
robinr	not sure that helps	00:12
michael__	Well, I'll look into the dns. But I can't imagine that's the reason.	00:12
robinr	if reverse lookup isn't working the login will wait for the lookup to timeout	00:12
michael__	I'm pretty sure I've got everything configured right	00:12
robinr	ofcourse if you have a heavily loaded server that's a possibility	00:13
michael__	So basically a squash merge just gets rid of the history, right?	00:13
robinr	yes	00:13
michael__	Why would you ever want to do that?	00:13
	I don't see how that gets me to cvs	00:13
robinr	to get rid of the history	00:14
michael__	I'd need to make a giant patch	00:14
	and apply it in the cvs repo	00:14
robinr	that is exactly what the squash merge would do for you	00:14
michael__	I see	00:14
	It would squash all the history into one commit	00:14
robinr	you can drop it after that and keep your git history	00:14
michael__	hee hee; my fatigue is showing. I still don't see it.	00:16
	I don't need to merge with a git branch	00:16
	← moh left	00:16
robinr	I'm assuming your 60 commits are in an uninterrupted commit chain	00:16
michael__	yes	00:16
robinr	create a temp branch from the parent of the first commit	00:16
	then git merge --squash lastcommitofthose60	00:17
	git-cvsexportcommit -u -c HEAD	00:17
	← KirinDave left	00:17
michael__	I see now. I'm still getting used to the liberal use of branches in git	00:17
	It's a different way of thinking, and one that I like. But I'm still a novice for sure.	00:17
	→ cortila joined	00:18
	← cortilap left	00:18
robinr	git allows you to think differently	00:18
	→ Pistahhh joined	00:19
	← jwb_gone left	00:20
robinr	is that "think different"? :)	00:20
	← sadrul left	00:20
michael__	:)	00:22
	robinr thinks sleep	00:26
	← csc` left	00:29
	→ csc` joined	00:31
michael__	I do to	00:31
	Have a good night	00:31
	and thanks	00:31
	← michael__ left	00:31
	→ jtoy__ joined	00:32
	← saintdev_ left	00:34
	→ saintdev joined	00:37
	← Pistahh left	00:38
	Pistahhh → Pistahh	00:38
	← bfields left	00:39
	→ moh joined	00:49
	← rtmfd_icbm left	00:59
	→ jerbear joined	01:03
	→ branstro1 joined	01:04
	→ agoode joined	01:05
	→ bdiego joined	01:05
	→ rtmfd_icbm joined	01:09
	← rtmfd_icbm left	01:14
	← branstrom left	01:14
	← REPLeffect left	01:16
	→ toidinamai joined	01:19
toidinamai	Hello.	01:19
Tene	Hi!	01:20
toidinamai	If cogito is "slowly being phased out" what is an alternative? Raw git?	01:20
aeruder	toidinamai: yea, back many moons ago git was very low level	01:21
	that is no longer the case	01:21
toidinamai	Is there a "git for cogito users"?	01:22
	← bdiego left	01:29
	→ twilight\ joined	01:31
	← fowlduck left	01:31
	→ FunkeeMonk joined	01:33
	→ FunkeeMonk_ joined	01:42
	← matteo left	01:52
	→ orospakr joined	01:54
	← aroben left	01:58
	→ aroben joined	01:59
	← FunkeeMonk left	01:59
	FunkeeMonk_ → FunkeeMonk	02:00
	← sgrimm left	02:04
	→ fowlduck joined	02:13
	→ bdiego joined	02:21
	← madewokherd left	02:21
	branstro1 → branstrom	02:29
	← metafollic left	02:44
	→ glguy joined	02:47
	→ REPLeffect joined	02:48
	← FunkeeMonk left	02:50
	→ metafollic joined	02:51
	← REPLeffect left	02:52
	→ KirinDave joined	02:52
	→ REPLeffect joined	02:55
	← metafollic left	02:59
	→ metafollic joined	03:09
	→ madewokherd joined	03:09
	← KirinDave left	03:10
	← orospakr left	03:11
	← saintdev left	03:13
	→ saintdev joined	03:13
	← glguy left	03:13
	→ glguy joined	03:15
	← jerbear left	03:19
	← metafollic left	03:27
	→ fhobia joined	03:29
	→ Muta joined	03:29
	→ metafollic joined	03:30
	← dduncan left	03:31
	← bdiego left	03:35
	← saintdev left	03:39
	→ saintdev joined	03:41
	← jtoy__ left	03:43
	→ wolf^_ joined	03:43
	← agoode left	03:44
	← wolf^ left	03:45
	← rodserling left	03:45
	wolf^_ → wolf^	03:45
	← adante left	03:48
	→ orospakr joined	04:03
	← Sho_ left	04:07
	← metafollic left	04:07
	→ metafollic joined	04:10
	← aroben left	04:11
	→ wolf^_ joined	04:13
	← wolf^ left	04:15
	wolf^_ → wolf^	04:15
	→ mgrimes joined	04:21
	← mgrimes left	04:22
	→ mgrimes joined	04:23
	← jcollie left	04:25
	← rkaway2 left	04:26
	→ rkaway2 joined	04:29
	→ wolf^_ joined	04:34
	← wolf^ left	04:34
	wolf^_ → wolf^	04:35
	← fhobia left	04:39
	← Sonderblade left	04:40
	← madewokherd left	04:44
	← mgrimes left	04:46
	→ spearce joined	04:47
	→ mgrimes joined	04:48
	→ aroben joined	05:01
	← doublec left	05:01
	→ rtmfd_icbm joined	05:03
	← rtmfd_icbm left	05:05
	← leonardop left	05:10
	→ theCarpenter joined	05:19
eMBee	good afternoon	05:23
	how can i merge/cherry pick/ commits from a submodule into the main repo?	05:24
gitwump	use git format-patch, and then git apply	05:25
	but it sounds like an odd thing to want to do	05:25
eMBee	well, my problem is that i have two repos for the same code	05:26
	one is the upstream library, and another is our companies svn repo	05:26
gitwump	right, well normally you manage that with branches in a single repo, not submodules	05:26
eMBee	i pull updates from upstream and then need to copy them into the work svn repo	05:26
spearce	gitwump now? hmmph. maybe i should switch to my "real" nick... ;-)	05:27
gitwump	oh yeah maybe I should change that back	05:27
	→ dduncan joined	05:28
eMBee	well, the library is in a subdirectory so i thought a submodule would be a good approach	05:28
	← halfline left	05:28
	→ Teln1100A joined	05:28
gitwump	ideally the submodule structure would resemble the upstream structure	05:30
eMBee	well, i sort of have two upstreams	05:31
	← Pistahh left	05:31
gitwump	doesn't matter	05:31
eMBee	the problem really is that svn doesn't handle submodules	05:32
gitwump	it has svn:externals which are a similar feature	05:32
	apparently, never used them myself	05:32
	eMBee looks at that	05:34
eMBee	hmm, indeed, that might help	05:35
	i'd need to create another svn repo for it though, but that may not be a bad idea	05:36
	i was kind of hoping that i could use submodules as if they were part of the main repo, have the branches show up in gitk and be able to copy changesets around so that local and remote repo do not need to be set up identically	05:39
	← robinr left	05:40
gitwump	are both the upstreams svn?	05:40
eMBee	no, only one	05:40
gitwump	the svn one has the library as a sub-dir?	05:40
eMBee	and technically i do have access to the svn server so i can make changes there	05:40
	yes	05:40
gitwump	extract the library on its own using git-svn	05:41
	track the other one as another branch	05:41
	then merge will work fine	05:41
eMBee	that idea crossed my mind	05:41
gitwump	who are you tracking an svn repo and getting submodules out of it anyway?	05:41
eMBee	but how will the main checkout react? since that will checkout everything with the subdir included	05:41
gitwump	s/who/how/	05:42
eMBee	i am not getting submodules out of svn so far	05:42
	→ Pistahh joined	05:42
eMBee	how does the submodule stuff work in general, if i pull from repo A, and then add a submodule in /lib/; while A itself does not have such a submodule. then someone else working on A puts stuff into lib, unaware that i have a submodule there. what will git do when i fetch from A again, pulling that new lib, conflicting with the one i have	05:46
	→ spearce_ joined	05:48
	← spearce left	05:48
	→ rtmfd_icbm joined	05:51
	→ hiarc joined	06:00
	← DrNick left	06:03
	← engla left	06:04
	← metafollic left	06:07
	→ engla joined	06:08
	→ metafollic joined	06:13
cehteh	eMBee: when you found a convinient solution, tell me .. i still reject using submodules for svn synced stuff :)	06:14
	→ mwansa joined	06:22
	← sinequanon left	06:24
	→ Evelynn joined	06:24
	← aroben left	06:41
	→ aroben joined	06:48
	→ sgrimm joined	06:52
	← spuk- left	06:54
	← REPLeffect left	07:12
	← kanru left	07:15
	← spearce_ left	07:17
	→ namenlos joined	07:18
	← rtmfd_icbm left	07:22
	→ kanru joined	07:41
	← jaalto left	07:55
	← aroben left	07:58
tsuna	I have a branch A and a branch B, and I'd like to check whether branch A's head and branch B at a given commit have the same content in src/network only.	08:02
	Is git diff 9cc58f38 HEAD -- src/network the right thing to do? Where 9cc58f38 is the commit in branch B and HEAD is because I'm currently on branch A.	08:03
	I'm asking because I do see diffs but this is a git-svn repo and doing the same diff in SVN doesn't show any diff: svn diff -r<revision of 9cc58f38> https://host/svn/proj/{trunk,branches/2.0}/src/network	08:04
	So maybe I'm misunderstanding what git diff showed me or maybe I'm not using svn correctly (but that's another story).	08:04
	→ alley_cat joined	08:05
MadCoder	git diff A..B -- src/network	08:07
	tsuna: ^^	08:07
glguy	git diff A B -- src/network == git diff A..B -- src/network	08:08
	which is what he said he typed?	08:08
tsuna	Indeed.	08:09
MadCoder	git diff A..B is not the same as git diff A B	08:09
	is it ?	08:09
tsuna	It is the same, look at a recent man git-diff.	08:09
MadCoder	A..B is supposed to be ^A B ?	08:09
tsuna	It's a common misunderstanding.	08:09
glguy	MadCoder: I'm not testing it, just quoting the man page	08:10
MadCoder	hmm I stand corrected	08:10
tsuna	git diff is meant to diff two trees, and the fact that people are used to the notation A..B for other commands (to express a range of commit) leads them to think that they have to use A..B for git diff which silently accepts it as A B.	08:10
MadCoder	those X..Y inconsistencies drives me crazy :)	08:10
tsuna	AFAIK it's the only inconsistency when it comes to A..B.	08:10
MadCoder	though it's an inconsistency that makes sense, and I now remember that this was indeed discussed recently	08:11
glguy	what is the inconsistency?	08:11
	A..B means everything after A upto and including B, right?	08:11
MadCoder	A..B means ^B A everywhere else	08:11
tsuna	Yes but not for git-diff.	08:11
	← mwansa left	08:12
MadCoder	glguy: it does not means "after"	08:12
	A..B means every commit that is an ancestor of B but not of A	08:12
glguy	right	08:13
	which is different in the case of a fork?	08:13
MadCoder	and A..B is ^A B not ^B A	08:13
glguy	from the other form?	08:13
MadCoder	A B means every ancestor of A _and_ every ancestor of B	08:13
gitster	diff is special.	08:13
	diff is about two points, never about ranges.	08:14
MadCoder	gitster: yeah when you think about it it's obvious	08:14
gitster	so A..B == ^A B does not apply.	08:14
MadCoder	I was just confused because of lack of caffeine	08:14
glguy	it just grabs the two trees	08:14
	and shows the differences?	08:14
MadCoder	yes	08:14
glguy	is what makes it special?	08:14
gitster	It is just to save older people (read: Linus) from common typos, as they are so used to the range notation used in logs.	08:14
MadCoder	haha	08:15
gitster	I am not joking. Look for an article by Linus in the list archive. He responds to a complaint "why do you have both diff A..B and diff A B" with "you do not have to use A..B if you do not like it".	08:17
MadCoder	it nontheless makes me laugh	08:17
gitster	In the hindsight, we probably should have used A...B form for two point diffs, but it is too late now. Three-dot range is much later invention.	08:19
	← Pistahh left	08:22
	→ marcel joined	08:24
	→ Pistahh joined	08:24
	← dkagedal left	08:25
	→ dkagedal joined	08:27
	→ Dodji joined	08:29
	→ elmex joined	08:35
tsuna	Say I have a repo in which a library was developed. Now I have other repos, with other projects that wish to use this library. Thus, I'd like to take that lib out of its current repo and put it in its own one so that other projects can have it as a submodule.	08:39
	Is it possible to easily extract the history of the subdir of that lib to replay it in a new repo?	08:40
	← namenlos left	08:40
MadCoder	in theory git-filter-branch knows to do that	08:40
tsuna	I mean, I can easily script this and diff each rev with the following, going from the 1st to HEAD, and doing the diff only for the subtree where the lib is.	08:40
MadCoder	though when I tried it last time, it gave me a ridiculously small history	08:40
	and I've not been able to track the issue yet	08:40
tsuna	But how can I preserve the various other stuff such as timestamps, authorship, etc?	08:41
MadCoder	i just said it	08:41
	tsuna is RTFMing	08:41
tsuna	thanks for the pointer.	08:41
	→ ageo___ joined	08:44
MadCoder	hmm --subdirectory-filter (which is what you want) does not work here	08:45
gitwump	yeah, git filter-branch with the tree filter, but you'll also need a parent filter that obliterates commits that didn't touch the path you wanted	08:45
MadCoder	ohh so that's why I have a very short history then	08:45
	because it breaks at the first point where the commit did nothing in that path	08:45
	it's a shame --subdirectory-filter does not this on its own	08:46
gitwump	well, that may be a bug. first I've seen that option	08:46
	you've also got the question about what do you do if the path is moved around	08:47
	← ageo___ left	08:49
	→ Yuuhi joined	08:49
	← sgrimm left	08:55
	← yorgen1555 left	08:59
	← kanru left	09:04
	→ robfitz_ joined	09:09
	← robfitz left	09:11
Catfish	I have a file in my working copy that I've modified, and would like to revert some of the changes back to how they were at the last checkin. Is there an easy way of pulling up a merge tool for that?	09:19
MadCoder	a merge tool huh ?	09:21
	you can probably do: vimdiff path/to/your/file <(git show :path/to/your/file)	09:22
	(you can adapt it to the $tool of your choice of course)	09:23
Catfish	Bah, I can't persuade opendiff to work from stdin. Guess I'll have to figure out how vimdiff works...	09:27
Mikachu	git-mergetool -t vimdiff ?	09:28
	→ yorgen1555 joined	09:33
	← glguy left	09:33
	← toidinamai left	09:33
	→ felipec joined	09:34
felipec	is it possible to clone specific directories with git-svn?	09:35
	I'm trying https://omxil.svn.sourceforge.net/svnroot/omxil/libomxil/trunk	09:36
	but it only works when I remove libomxil/trunk	09:36
MadCoder	Catfish: yes you can using what I just said	09:38
	<(foo) is to be used as a file name	09:38
	works in bash and zsh at least	09:38
gitwump	felipec: nopaste your errors?	09:39
Catfish	MadCoder: Hmm, I can't persuade that to work in anything except vi	09:42
	emacs, textmate, and opendiff all seem to be unable to read from <(foo)	09:42
irons\|lunch	i like how if you get conflicts during a rebase and want to abandon the whole idea, u can do "git rebase --abort". Does 'git merge' have something similar? I've seen lots of ppl screw up their merges and wish they could just start over	09:42
	irons\|lunch → up_the_irons	09:42
felipec	gitwump: for some reason it doesn't seem to be working anymore	09:43
	but I got errors like these:	09:43
	http://www.spinics.net/lists/git/msg42422.html	09:43
MadCoder	Catfish: then they suck	09:43
	use an intermediate temp file then	09:43
Tv	felipe: try git-svn clone --trunk trunk --branches branches --tags tags https://omxil.svn.sourceforge.net/svnroot/omxil/libomxil/	09:44
felipec	felipec: but I don't want all that stuff, just the trunk	09:45
Tv	felipe: try leaving out --branches and --tags, then	09:45
up_the_irons	Tv: Tv !	09:47
Tv	hehe	09:48
up_the_irons	Tv: I'm writing this up: http://cheat.errtheblog.com/s/git	09:48
felipec	Tv: I got a libomxil directory with a bunch of .git stuff but nothing more	09:48
gitwump	I am cloning that url now and it's working	09:48
Tv	up_the_irons: how's that different from the n+1 existing ones?-)	09:48
gitwump	felipec: does git-fsck say anything about dangling commits?	09:48
Mikachu	up_the_irons: maybe you want git-reset --hard?	09:49
felipec	gitwump: notice: HEAD points to an unborn branch (master)	09:49
gitwump	anything in .git/objects ?	09:49
Tv	felipe: try git checkout -b master trunk	09:49
gitwump	ie, files	09:49
up_the_irons	Tv: not much, but rails kids like the 'cheat' gem (so they can just type "cheat git" in the terminal); I've been pushing hard to get Git into the rails community. It's working	09:49
Tv	up_the_irons: ror is nih-land..	09:50
gitwump	did you get much output like r64 = 2e1714fcdc6348d8f6aadf5c972ce32ffa886a57 ... ?	09:50
up_the_irons	Mikachu: yeah, was thinkin about the git-reset too..	09:50
felipec	Tv: git checkout -b master trunk	09:50
	git checkout: updating paths is incompatible with switching branches/forcing	09:50
	Did you intend to checkout 'trunk' which can not be resolved as commit?	09:50
Tv	felipec: "git branch -a"?	09:50
felipec	Tv: main_0_2_devel@122	09:51
	main_0_2_devel@65	09:51
Tv	that looks weird	09:51
gitwump	normal	09:51
felipec	gitwump: yes, lots of stuff	09:51
up_the_irons	I'm temped to add a "git-unfuck" command; tired of ppl messing up their merges and not knowing how to start over	09:51
gitwump	felipec: ok, so running git lost-found should give you some refs, one of which is hopefully your trunk	09:52
	I think this problem is fixed on next or possibly even maint	09:52
felipec	gitwump: git lost-found	09:53
	notice: HEAD points to an unborn branch (master)	09:53
gitwump	yes, it looks like git-svn did not finish	09:53
	you can fix that just by pointing master at any commit	09:53
	one of the dangling ones, for instance	09:54
Catfish	MadCoder: Ah. Just fwiw, opendiff foo =(git show :foo) works nicely	09:54
	(I think the difference is temporary files vs named pipes?)	09:54
Mikachu	file =(echo test) <(echo test)	09:55
felipec	gitwump: how do I do that? :>	09:55
gitwump	git update-ref refs/heads/master commitid	09:55
Catfish	Bash doesn't seem to like =(foo) - does it have an equivalent?	09:55
MadCoder	Catfish: maybe	09:55
Catfish	(I use zsh, so this is just for curiosity's sake...)	09:56
Mikachu	i saw a crazy page just 5 minutes ago, hang on	09:56
MadCoder	yeah seems so, :	09:56
	echo =(git show) <(git show)	09:56
	/tmp/zsheuM0Yb /proc/self/fd/11	09:56
Mikachu	http://home.eol.ca/~parkw/index.html , don't know if it's somewhere in there :)	09:56
MadCoder	I didn't knew about =(..) I shall say :)	09:57
felipec	gitwump: how do I find one of those commits?	09:58
gitwump	find .git/svn -name \rev\ -exec tail -1 {} \;	09:59
	is one place there should be some	09:59
	I just cloned that trunk successfully with git-svn 1.5.3.2	10:00
	if I were you I'd consider upgrading	10:00
felipec	gitwump: I think I'll do that... your instructions worked, but I think some commits are missing	10:02
	gitwump: git-svn --version	10:07
	git-svn version 1.5.3.2 (svn 1.4.3)	10:07
gitwump	:-/	10:07
	well the only difference for me is I'm running a newer svn	10:08
felipec	gitwump: I updated and still doesn't work	10:08
gitwump	oh, I also didn't use clone	10:08
felipec	I did: git-svn clone --trunk trunk --branches branches --tags tags https://omxil.svn.sourceforge.net/svnroot/omxil/libomxil/	10:08
gitwump	I did this: mkdir omxil; cd omxil; git init; git svn init https://omxil.svn.sourceforge.net/svnroot/omxil/libomxil/trunk; git svn fetch	10:08
Mikachu	i think -s is a shorthand for that	10:09
	hm, it refetches the same commits when following the parents of another branch	10:13
	seems sort of pointless	10:13
	since it'll just be the same set of files	10:13
felipec	gitwump: that worked	10:13
Mikachu	ie, it fetches the exact same svn rXXX again	10:13
gitwump	dealing with svn repos via the svn api is a black art at best	10:14
Mikachu	well, git-svn has git-svn find-rev, it could see if we already have the tree object for that commit	10:14
	(maybe) :)	10:15
	→ meandtheshell joined	10:16
	→ bentob0x joined	10:16
felipec	gitwump: git svn init https://omxil.svn.sourceforge.net/svnroot/omxil/libomxil --trunk trunk --branches branches --tags tags	10:18
	that doesn't work	10:18
gitwump	I've just set that going too	10:20
	it seems to be happening quite happily	10:21
felipec	gitwump: yeah, but at the end I have an unusable repo	10:22
Mikachu	what happens at the end exactly?	10:22
felipec	Mikachu: there are no files, there are no branches	10:23
Mikachu	i mean what does git-svn say?	10:23
felipec	Mikachu: nothing, it just finishes cleanly AFAIK	10:24
	→ Pistahhh joined	10:27
gitwump	the last line I see printed after the fetch is 'r311 = 67c42bbb071c084d542eacce7b67ef6a5ad31bd6 (trunk)	10:33
	and then I get left with a 'master' which is trunk	10:33
	you can have this clone if you promise to try to find out why mine worked and yours didn't :)	10:34
	← dduncan left	10:37
	← Pistahh left	10:44
	Pistahhh → Pistahh	10:44
	← branstrom left	10:50
	→ branstrom joined	10:50
	→ namenlos joined	10:55
	→ kanru joined	10:57
felipec	gitwump: hehehe	10:59
	gitwump: you used "--trunk trunk --branches branches --tags tags" ?	10:59
gitwump	yep	11:00
	→ mneisen joined	11:00
felipec	gitwump: the only thing I need to use the new git is to change my PATH, right?	11:00
gitwump	erm	11:01
	well, check with git --version which one you're getting	11:01
felipec	git version 1.5.3.2	11:03
Arjen	I did a little experiment last night and was a little surprised: from 2 files I moved identical functions to a new file. (from Foo.pm and Bar.pm to Foobar.pm) The 'git blame' command showed that the section came from Foo.pm, but the 'git log -p' showed a diff against Bar.pm. The result is of course the same, but I was surprised at the inconsistency. Any thoughts?	11:04
felipec	gitwump: so: git init, git svn init url --trunk trunk <snip>, git svn fetch	11:05
gitwump	right	11:05
	and eventually you get something like git://utsl.gen.nz/omxil	11:05
felipec	all right, this time I ran a shell script and saved all the output	11:11
	gitwump: I'm behind a firewall, I can't access through the git protocol	11:12
	→ mithro joined	11:13
	→ ferdy joined	11:13
mithro	shawn__: are you the infamous Shawn Pearce? :)	11:14
gitwump	felipec: ok, funny url, but you can clone http://vserver.utsl.gen.nz/git/omxil/	11:14
felipec	gitwump: all right, no, I get nothing like that	11:16
	gitwump: which version of svn are you using?	11:17
gitwump	mirror it with wget -r -np	11:17
	svn trunk from about 15 Sep	11:17
Mikachu	mithro: i think he goes by spearce	11:17
mithro	ahh	11:17
	← pigeon left	11:17
gitwump	if you mirror it you get to see what is different and hopefully see where your version starts to differ	11:17
	→ pigeon joined	11:33
felipec	gitwump: it's totally different	11:43
	gitwump: I have a bunch of .git/svn stuff, you don't have any	11:44
	hmm, maybe the mirror is not right	11:44
	← Evelynn left	11:47
felipec	gitwump: http://rafb.net/p/fliRmd70.html	11:49
	→ Sho_ joined	12:05
	← robfitz_ left	12:19
	→ agoode joined	12:22
	→ lcapitulino joined	12:23
Catfish	I applied half a patch, and committed the partially patched file. Now when I try and apply the patch again to try and get the remainder of the patch, it says patch does not apply. Is there any way of persuading it to do so, without manually editing the patch to remove the bits I've already applied?	12:24
	→ robfitz joined	12:30
felipec	how do I get git-svn to use another svn version?	12:30
	I have it in /opt	12:30
bentob0x	anybody bought an openmoko here?	12:30
Catfish	felipec: I don't know, but I'd imagine it uses your PATH variable. So if /opt/local/bin has priority, it'll use that	12:32
	→ cmarcelo joined	12:35
felipec	Catfish: it seems it's not	12:35
Catfish	Hm. What does 'type svn' show?	12:36
aeruder	i'd imagine git-svn uses the svn perl bindings	12:36
	→ jaalto joined	12:38
felipec	yeah, I think it uses the perl bindings	12:39
	← fowlduck left	12:39
eMBee	yes, it does use the perl bindings	12:40
tsuna	felipec: I think (unsure) that you can try to export GITPERLLIB so that it points to the site_perl directory under /opt (most probably /opt/local/lib/perl5/site_perl/5.8.8 or something like that)	12:40
felipec	tsuna: that's for the git stuff isn't it?	12:47
tsuna	Yes, it's a wild guess after having a quick look at git-svn	12:47
	← marcel left	12:48
felipec	tsuna: it might work once I fix one thing	12:50
	→ marcel joined	12:50
felipec	all right	12:53
	export GITPERLLIB=/opt/svn/lib/perl5/site_perl/5.8.8:/opt/git/lib/perl5/site_perl/5.8.8	12:54
	export LD_LIBRARY_PATH=/opt/svn/lib	12:54
	that did the trick	12:54
	← mneisen left	12:55
	→ Pistahhh joined	12:58
	← branstrom left	13:00
	→ branstrom joined	13:00
felipec	gitwump: I tried with svn 1.4.5 and I still have the same issue	13:06
tsuna	Grrr I hate SVN. Merging is so much uber-b0rken.	13:07
	← Pistahh left	13:11
	Pistahhh → Pistahh	13:11
	← jlh left	13:11
	→ jlh joined	13:11
	← moh left	13:15
	→ madewokherd joined	13:17
	→ bdiego joined	13:19
	→ moh joined	13:20
	→ spuk- joined	13:25
	← agoode left	13:25
	→ halfline joined	13:28
	← halfline left	13:28
	→ halfline joined	13:28
	← Ingmar left	13:32
	→ Ingmar joined	13:33
thiago	how do I do a diff on a single file between two revisions, if the file has been renamed in-between?	13:38
	interesting, add --	13:38
tsuna	? how?	13:39
thiago	ah, no	13:39
	it's the wildcard	13:39
	← engla left	13:42
	→ Ryback_ joined	13:46
	← halfline left	13:46
	→ halfline joined	13:47
	→ GyrosGeier joined	13:50
	→ jackbravo joined	13:53
	← branstrom left	13:54
felipec	gitwump: I tried with latest svn, still the same result :'(	13:55
	← orospakr left	13:56
	→ Oejet joined	14:14
	→ FunkeeMonk joined	14:15
madduck	MadCoder: I tried to follow your instructions for the vim git-commit plugin but if i put the autocmd into .vim/filetype.vim, the result is still ft=conf...	14:19
MadCoder	madduck: my conf is online and works for me	14:21
	http://madism.org/~madcoder/dotfiles/vim/	14:21
	note that the "plugin" does not what it should for merge commit, or --amend ones though	14:22
	(or maybe even for ones with some bits in the index and some not)	14:22
	and it has other shortcomings as well.	14:22
	I should work on it, but I'm too lazy	14:22
	patches welcomed	14:22
madduck	k	14:26
	→ Pistahhh joined	14:26
madduck	would you mind if we changed the filetype from git to git-commit?	14:26
	MadCoder: btw:	14:27
MadCoder	I absolutely don't care	14:27
	(meaning no I don't mind)	14:28
madduck	au! BufRead,BufNewFile .msg.[0-9]*	14:28
	\ if getline(1) =~ '^From .\+ignored\.$' \| setf mail \| endif	14:28
	for git-send-email	14:28
	i am going to try to get this stuff into vim-runtime	14:28
MadCoder	it's in vim-scripts btw	14:28
	(I think)	14:28
	→ reinhold joined	14:28
madduck	yeah, i mean that.	14:28
	but the filetype detection can go to vim-runtime, really.	14:29
MadCoder	in fact I think it's already here	14:30
madduck	i don't think so.	14:30
MadCoder	indeed	14:30
madduck	but i'll check that of course	14:30
MadCoder	it's not here	14:30
	I just hceked	14:30
	checked	14:30
	→ sgrimm joined	14:36
	← kanru left	14:38
	← Pistahh left	14:40
	Pistahhh → Pistahh	14:40
	→ orospakr joined	14:44
	→ wacky_ joined	14:46
wacky_	Hey bundles are neat!	14:46
	→ engla joined	14:46
wacky_	but there is a little bug in git-fetch when fetching from a bundle	14:47
	→ KirinDave joined	14:51
	← KirinDave left	14:52
coopsh	Can somebody point me to a manual page of gitweb? I want to have a set of distinct git repositories in the web interface	14:58
	← sgrimm left	14:58
Mikachu	i think the easiest way is to make a subdir and symlink the wanted repos there	15:00
Catfish	I applied half a patch, and committed the partially patched file. Now when I try and apply the patch again to try and get the remainder of the patch, it says patch does not apply. Is there any way of persuading it to do so, without manually editing the patch to remove the bits I've already applied?	15:00
Mikachu	Catfish: how about reverting the partial commit and then applying the patch?	15:00
Catfish	Mikachu: Mm.. the reason I was trying to separate it was its patching 2 totally separate things	15:02
Mikachu	are they in separate files?	15:02
Catfish	No, it's a single file	15:02
Mikachu	but the hunks are completely separate?	15:02
Catfish	Yeah	15:02
Mikachu	then just apply it with 'patch'	15:03
	it'll skip hunks that reject and apply the rest	15:03
Catfish	ah	15:03
Mikachu	i think :)	15:03
	try it and commit, then try a patch -R	15:03
	or	15:03
	git reset --mixed to before you apply, then apply it and commit	15:03
	hm not --mixed	15:03
	isn't there a git reset --something that resets the working tree but not the index?	15:04
	heh	15:04
	anyway, you could get the file from before the partial commit and apply the patch in full, and git would only see the new changes then	15:04
	← moh left	15:05
Catfish	Do you usually have to use -p1 with git patches, to get around the --- a/file.c +++b/file.c ?	15:06
Thumper_	Catfish: yes	15:07
Catfish	fair enough. Just checking I wasn't doing something wrong...	15:07
	reinhold → reinhold_away	15:07
	← Oejet left	15:11
	→ michael joined	15:13
michael	Hello. Is there a way to compile git completely statically even though there are only shared libraries? I'd like to use the same binaries across different computers.	15:14
	In other words, I'd like to know if there are some flags to set during compilation	15:14
	I tried LDFLAGS=-static	15:14
	but that didn't help; apparently that only looks for static libraries.	15:14
	Perhaps it is not possible unless static libraries are around? I would think that shared library code could be linked in statically. Am I wrong about that?	15:15
vmiklos	correct	15:16
	you need the static version of each lib if you want to compile something statically	15:16
	and in case of git, you still need perl (and other deps) since not every git command is a builtin (writte in C)	15:16
	← bentob0x left	15:16
michael	Perl is ok	15:17
	But things like libcrypto vary in version	15:17
	→ Timotheo joined	15:17
michael	I don't understand why dynamic symbol lookup/translation cannot be done at static link time	15:17
	→ moh joined	15:18
	← halfline left	15:18
	→ halfline joined	15:19
	← Aeternus left	15:20
	→ Aeternus joined	15:20
	← Aeternus left	15:21
vmiklos	it can be done	15:22
	if you have the static libcrypto libs compile-time then you won't need them	15:22
	← FunkeeMonk left	15:23
michael	I don't	15:24
	I'd like to do the dynamic look up at compile time rather than runtime	15:24
	This seems like a pretty simple idea; I'm finding it hard to believe it's not possible.	15:24
	← theCarpenter left	15:25
	← wacky_ left	15:25
michael	To be exact.... I'm not sure why there are two types of libraries. There should be one type with which a binary can be statically or dynamically linked	15:25
	→ krawek joined	15:25
	→ Aeternus_ joined	15:25
	← marcel left	15:26
vmiklos	heh	15:28
	this is quite offtopic here..	15:28
Mikachu	michael: there is http://statifier.sourceforge.net/ but it produces slightly larger binaries than you get when compiling statically	15:28
	it seems to be possible to create a shared library from a static one, ar x file.a, ld -shared *.o -o file.so	15:32
	haven't tried actually linking to it though	15:32
	→ spearce joined	15:35
	→ robinr joined	15:37
	→ dsop joined	15:38
dsop	hmm is there a way to import mercurial repositories into git?	15:38
MadCoder	probably tailor	15:39
robinr	hgtogit	15:45
	in contrib I think	15:45
Ilari	Mikachu: Don't do that.	15:46
	→ p4tux joined	15:46
Mikachu	which part?	15:46
Ilari	Mikachu: For one thing, the thing will then contain lots of text relocations, pretty much negating any memory benefit. Secondly, SELinux doesn't like libraries performing text relocations very much.	15:47
	→ praka joined	15:48
	→ branstrom joined	15:49
	→ krh joined	15:49
	← praka left	15:50
madduck	MadCoder: http://git.madduck.net/v/misc/vim-git.git	15:51
	and anyone else using vim...	15:51
	tpope started this, i added git-send-email	15:51
	patches welcome.	15:52
	his repo: git://git.tpope.net/~tpope/vim-git.git	15:52
coopsh	once I did git-cvsimport I just want to do a git pull the next time	15:53
	what do I have to configure?	15:53
Mikachu	no, you have to run git-cvsimport in the future too	15:53
michael	Mikachu: I gave statifier a try. It's too rough and wants to be installed in the wrong places.	15:55
Mikachu	okay, i've never tried it myself	15:55
michael	thanks though	15:55
tokkee	madduck: Are you going to (try to) push it into git-core?	15:56
madduck	tokkee: i was thinking more vim-runtime	15:56
	but yes.	15:56
	definitely debian, hopefully upstream.	15:56
tokkee	madduck: I think it rather belongs into git-core. Else you'd have to upgrade vim-runtime in order to get a "complete" git upgrade...	15:57
madduck	huh?	15:57
tokkee	"complete" as in: including the (git related) vim stuff ;-)	15:57
madduck	ls /usr/share/vim/vim71/ftplugin /usr/share/vim/vim71/syntax	15:58
	these are vim syntax files, i think they should be shipped with vim	15:58
	okay, in this case you are probably never going to need them without git installed	15:58
	but actually, yes... vim .git/config	15:59
	no, i think they belong in vim-runtime	15:59
tokkee	Well, you could argue either way - do what you like most ;-)	15:59
madduck	true	15:59
	tpope: can i write a mail to the list and invite more testers?	16:00
	don't want to hijack your project	16:00
tpope	please do	16:01
	I'd love to but someone had the brilliant idea of having the programmer help with the office move	16:01
madduck	hehe	16:01
michael	Mikachu: Well, I've got it running after some hacking about. Let's hope it works!	16:03
	← thiago left	16:04
tpope	"it's a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change"	16:07
	is there a particular origin of that 50, and should "less than" be read as "no more than"?	16:07
	← z3ro left	16:07
MadCoder	mailers like mutt and others prints the date and sender and some things then the subject	16:13
	and you don't want it to clip	16:13
	that gives around 50 chars then	16:13
	I suppose that's where the limit comes from	16:13
	(and if it's not for _this_ reason, I suppose it's for one that is isomorph to this one)	16:14
tpope	I get why in general, I was wondering if 50 is special	16:15
MadCoder	a terminal is 80 chars	16:15
	do the math	16:15
	:)	16:15
	→ z3ro joined	16:15
madduck	MadCoder: git-core on backports.org depends on lenny's libc6...	16:15
	→ KirinDave joined	16:16
MadCoder	madduck: really ? FSCK	16:16
	I did it again	16:16
tpope	special might be "such and such log format shows 30 columns of metadata and leaves the rest for the log message"	16:16
madduck	i think so.	16:16
MadCoder	yeah used the wrong pbuilder	16:16
	→ drizzd_ joined	16:16
madduck	MadCoder: http://svn.madduck.net/pub/bin/debian/dbuild automatically guards against that, might be trivial to add something like that to your scripts...	16:17
MadCoder	madduck: rebuild in progress	16:17
madduck	MadCoder: :)	16:17
	i love debian turnaround times.	16:17
	← michael left	16:17
tpope	I am asking because I am flagging characters after 50 as an error in the syntax file, but that seems silly if 50 is just a rough guideline	16:17
MadCoder	yeah I should have a guard in my [builder	16:17
	→ fhobia joined	16:17
	→ strangy joined	16:17
MadCoder	tpope: I think it's a rough guideline	16:18
madduck	tpope: maybe use something other than error.	16:18
MadCoder	well actually I'm sure	16:18
madduck	i think it's cool that they're highlighted	16:18
tpope	okay	16:18
	I can just highlight the first 50 special	16:18
MadCoder	madduck: thanks to have spotted that btw	16:18
madduck	tpope: it should definitely be an error if line 2 is non-empty...	16:18
	not sure if you can encode that	16:18
	← z3ro left	16:19
tpope	you think so?	16:19
MadCoder	yes	16:19
	you should check that, it gives really awkward issues	16:19
madduck	which does seem silly	16:19
MadCoder	and yes madduck it's doable	16:19
madduck	everything is doable in vim...	16:19
tpope	probably, I just think that's less useful to convey (I know to leave the second line empty, but getting it under 50 takes more care)	16:19
robinr	coopsh: set up a separate repo for cvsimport (or some other better alternative) in a cron job. Then you can pull from that one.	16:20
coopsh	robinr: nice idea.	16:21
tpope	git log --pretty=oneline actually leaves just 39 characters for the log message :/	16:21
	← spearce left	16:23
	→ gitte joined	16:24
coopsh	tpope: do you know of a public vim git repository?	16:24
tpope	you mean for vim as a whole? no	16:24
	there's cvs mirrors and svn mirrors	16:24
gitte	Google comes up with this: http://git.altlinux.ru/archive/v/vim.git/	16:24
	Not even half a minute of a search ;-)	16:24
robinr	coopsh: I've done that since about a year ago, but switch to fromcvs later on since cvsimport had a tendency to break occasionally	16:24
coopsh	yes, but I tought of a 'trusted' source ;)	16:25
gitte	http://ftp.altlinux.com/pub/people/raorn/scm/packages/vim.git/ better?	16:25
robinr	break = create broken imports	16:25
coopsh	gitte: okay okay ;)	16:25
gitte	coopsh: FWIW I'd fetch both, compare the commit names of "master", and be reasonably certain that no tinkering took place if both are identical.	16:27
madduck	coopsh: or make one on repo.or.cz and announce it to the vim list	16:27
	→ z3ro joined	16:27
gitte	To be sure, I'd then checkout the official sources, import that into git, and compare the tree names.	16:27
coopsh	hehe	16:28
	→ aroben joined	16:29
	← drizzd left	16:30
	← orospakr left	16:30
robinr	I have made occasional cvs checkout and diff'ed with the git checkout. that is the only reliable way. I don't trust the two exporters to check each other	16:32
	→ sgrimm joined	16:32
robinr	there is one thing not to do with fromcvs. don't let anyone but fromcvs mess with it, i.e. don't push to it.	16:32
	→ HackyKid joined	16:33
	→ branstro1 joined	16:33
gitte	Hi HackyKid!	16:34
	Thank you very much for msysperl	16:34
HackyKid	heya gitte	16:34
	heh, you're welcome :-)	16:34
	did you test if it works for you too?	16:35
gitte	Sorry, didn't have time yet.	16:35
HackyKid	ah	16:36
	robinr <3 rebase -i	16:36
gitte	robinr: something wrong?	16:36
robinr	no, not at all :)	16:37
	missing gui perhaps	16:37
gitte	robinr: sorry, I could not interpret "<3" as anything else than "I sh*t on".	16:37
robinr	I don't use stacked git anymore	16:37
	it's a heart,	16:38
gitte	Oh.	16:38
	;-)	16:38
tpope	well madduck, thanks for drawing attention to the fact I had failed to add the right email to .gitconfig on my server box :)	16:38
robinr	maybe only known on swedish channels :)	16:38
gitte	Isn't there some UTF-8 character for a heart?	16:38
	→ Oejet joined	16:39
robinr	yes ♥	16:39
gitte	Hehe.	16:39
HackyKid	acii 1 or so it a heart too :-p	16:39
gitte	A black heart.	16:39
HackyKid	hmm, no, not 1 i think	16:39
gitte	HackyKid: is it? Or is it some DOS code page?	16:39
robinr	no, it's a control character (invisible)	16:39
madduck	tpope: lol. :)	16:39
robinr	on commodore 64 maybe	16:40
HackyKid	ah, yeah, probably the DOS code page yeah	16:40
robinr	not DOS	16:40
	it's control characters there too	16:40
HackyKid	yeah, but they are visible there	16:41
	well, they can be	16:41
tpope	I don't suppose I can fix that in the repo without screwing up everyone who cloned from me can I?	16:41
HackyKid	and if you directly write to video mem (which you do for speed :-p), its not interpretted as control char	16:41
	← KirinDave left	16:42
	workkevin seems to recall ASCII 1 being SOH (start-of-header), whatever that means	16:43
robinr	exactly that	16:43
	header starts here	16:43
HackyKid	yeah, but heart wasnt 1, 1 was a smilie face or somehting	16:43
workkevin	I've seen it used in some network protocols to indicate -- you'll never guess -- the start of a header	16:43
robinr	synchronous block mode terminals, 3270 styöe	16:44
Ilari	U+2661 and U+2665 are hearts...	16:44
HackyKid	i used it as the 'player' in the first games i made :-p	16:44
	← fhobia left	16:45
robinr	syncronous serial protocols send NUL's instead of nothing, so 0x01 is the signal that means, listen up	16:46
	quite obsolete nowadays	16:46
	→ leonardop joined	16:46
Ilari	Most linux terminal emulators print nothing for NUL.	16:47
robinr	true, but otoh, they use asynchronous serial protocols so when there is no data they don't even get NUL characters	16:47
Ilari	I meant it as: "Maybe a leftover from those days"...	16:48
	← branstrom left	16:48
robinr	i doubt linux ever had to deal with synchronous serial protocols	16:49
	kind of old, very old "IBM:ishy" thing	16:49
Ilari	robinr: Yes, not Linux, but if some older Unix had to deal with them...	16:50
robinr	thay may be true	16:52
	still I think communications hw probably listened to those characters and filter out the non-data NUL's	16:52
	just like asyncrhonous hw takes care of the start and stop bits	16:53
Ilari	Probably Unix also has had to deal with them... Look up "screaming tty"...	16:56
	branstro1 → branstrom	16:56
	← anonuser left	16:57
	→ anonuser joined	16:57
robinr	doesn't sound like the same	16:58
	← namenlos left	16:58
Ilari	robinr: Do RS232 ports (when connected with minimum wiring) scream?	16:59
	robinr: Or actually not connected...	17:00
robinr	not unless badly wired, but probably could if connected to someting without or with bad ground	17:02
	nevertheless RS232 is not synchronous	17:02
Ilari	robinr: No, they don't scream.	17:03
	→ rtmfd_icbm joined	17:03
	→ KirinDave joined	17:03
	← cortila left	17:05
gitte	robinr: I played with the idea of putting something like rebase -i into git-gui...	17:07
	→ drizzd joined	17:08
robinr	not gitk?	17:14
	← engla left	17:15
krh	fonseca: what do you think about this parse_options() behaviour:	17:19
	* parse_options() will filter out the processed options and leave the	17:19
	* non-option argments in argv[]. The return value is the number of	17:19
	* arguments left in argv[].	17:19
Mikachu	how about passing in &argc and &argv?	17:19
krh	that's what I did before	17:20
Mikachu	ah	17:20
krh	but (*argv)++ and the like is kinda icky	17:20
Mikachu	char *argv = argv_p;	17:21
krh	sure... but this feels like a better api to me	17:21
Mikachu	but uh, if you don't pass in the pointer to argv, how does the caller know where the changed argv is?	17:22
krh	Mikachu: you just change the pointers in argv[]	17:22
Mikachu	ah right, i am silly	17:22
workkevin	Technically I don't know if you are supposed to do that	17:22
	Strictly speaking	17:22
Mikachu	as long as you don't need to grow the array	17:23
	then realloc might decide to move it	17:23
gitte	robinr: no, not gitk. It is a viewer. I find it disgusting that it learnt some non-viewing functionality which would belong into git-gui.	17:23
krh	yeah, we never need to grow, we're just picking out the options that have been handled	17:23
workkevin	Oh, are you guys not talking about the argv argument to main()?	17:24
Mikachu	can't do much about that one	17:24
krh	workkevin: we are, but why is that a problem?	17:24
gitte	krh: I usually do this thing with two counters, i and j, where i is incremented for every option, j only when a parameter was moved (to argv[j]).	17:24
workkevin	Well, the realloc... I wouldn't expect that to work on argv	17:24
krh	gitte: that's what I have here :)	17:24
	else if (!parse_one(argv[i], options, count, usage_string))	17:25
	argv[j++] = argv[i];	17:25
gitte	krh: heh.	17:25
	gitte likes it	17:25
gitte	;-)	17:25
krh	it's a nicer interface, fonseca had some good comments there	17:25
Mikachu	workkevin: hm yeah, maybe not realloc but malloc and return another pointer	17:25
	← drizzd_ left	17:25
Mikachu	workkevin: but in any case apparently we aren't doing either :)	17:25
krh	workkevin: ah, no, you can't realloc argv :)	17:26
Mikachu	if you do change the existing argv, won't that change what ps shows and what's in proc, etc?	17:26
	it would be weird if only the options passed to parse_options disappear :)	17:26
workkevin	I think in general I would not change argv, just on principle... but I don't know of a compelling argument, just a preference	17:26
Mikachu	maybe better to always allocate a separate argv** and play with that	17:27
	← strangy left	17:27
workkevin	FYI, I checked and the C standard explicitly says you CAN modified argv, including the strings themselves. I have no idea what the effect would be on proc.	17:30
gitte	We would not really break things here: revision.c already does it.	17:30
	I'd be surprised if proc shows anything different when you change argv[i].	17:31
	It should only change when you modify argv[i][j]	17:31
Mikachu	it seems modifying argv[i] is fine, but modifying argv[i][j] does affect /proc	17:31
	or what gitte said	17:31
gitte	Hehe.	17:32
Mikachu	i actually tried too :)	17:32
tokkee	Yes, that's how passwords are "hidden" from /proc afaik.	17:32
gitte	I tried to think how I'd implement the command line parsing ;-)	17:32
Mikachu	okay, then you can disregard everything i said before :)	17:32
	heh, you have to change every character to 0 apparently	17:33
gitte	Or to '*'	17:33
Mikachu	since /proc/pid/cmdline is NUL-separated already anywy	17:33
gitte	But putting pwds on the command line is _never_ safe.	17:34
	There is a time span -- however brief -- when it is visible.	17:35
Mikachu	of course, it's a race	17:35
	at the moment i am mostly amazed i remembered the argument order to memset()	17:35
workkevin	Yeah, there's a lot of inconsistency in arguments to memset-like functions, especially in C++	17:36
	I think C mostly uses the target, source order.	17:36
Mikachu	memset is target, data, length	17:36
workkevin	So you can remember it by the order being the same as target = source.	17:37
Mikachu	or you can consider data the source	17:37
workkevin	But then C++ copy() etc. are different, I think.	17:37
	Sorry for bringing up C++ here. I know it's a 4-letter word. ;)	17:38
gitte	workkevin: no problem. I do not have too much against C++.	17:39
	(Let the flame war start all over again...)	17:39
Mikachu	i have a better idea: don't let it :)	17:40
workkevin	Aaargh! I've been working on the wrong branch.	17:40
Mikachu	git checkout -m!	17:41
workkevin	I need some more of those 4-letter words now	17:41
	I think it's going to be a bit more tricky... I thought I did this yesterday, but I need to move all these changes to a different git-svn remote	17:42
	Oh, wait. Maybe I did do it yesterday.	17:43
	I think my git branch just has an unfortunate name.	17:44
	→ orospakr joined	17:44
gitte	workkevin: just rename it.	17:44
	git branch -m new-name	17:44
	Works on the current branch.	17:44
workkevin	I think I rebased it to where it needed to be, and left the name the same (refering to the original branch)	17:44
	Yeah, it's no problem. It just scared me.	17:45
	_tux68_ → loops	17:47
	→ wycats joined	17:57
wycats	Is there a way to push a local branch to the remote repository?	17:57
	→ chris2 joined	17:58
gitte	wycats: "git push <url> <branchname>"?	17:59
wycats	if I already cloned a remote repos	17:59
	so I would normally do git push	17:59
	can I do git push <branchname>	17:59
	?	17:59
	or can I just do git push from within the branch?	17:59
	← mgrimes left	18:01
gitte	No, you have to specify a remote name.	18:03
	But since you usually say "git push", I suspect that you want to push to the "origin" remote.	18:03
	("git push" is a shortcut for "git push origin <all-the-branches-you-have-in-common-with-origin>")	18:04
wycats	got it	18:08
	so git push origin <branchname>	18:08
gitte	Yes.	18:08
wycats	and the just git pull in the branch?	18:09
	or git pull <branchname>	18:09
gitte	git pull also wants a remote name first.	18:09
wycats	git pull origin <branchname>	18:10
	inside the branch?	18:10
gitte	Yep.	18:10
wycats	and how do I get rid of the remote branch when I'm done with it?	18:10
gitte	git push origin :<branchname>	18:10
	(Note the colon)	18:10
wycats	why doesn't git pull detect that you're in a branch and automatically pull from the remote branch, if it exists :P	18:10
	or wait	18:10
	will git pull get everything?	18:11
	including the branches?	18:11
	→ cortana` joined	18:11
Ilari	wycats: You can configure what branch from what remote 'git pull' fetches by default on per-branch basis.	18:12
wycats	ilari: is there docs somewhere on how to do that?	18:13
Ilari	wycats: The option names are 'branch.foo.merge' and 'branch.foo.remote' (foo is name of branch).	18:13
wycats	in .git?	18:14
Ilari	wycats: There is 'git config'.	18:14
wycats	ah	18:16
Ilari	wycats: It can be set up like: "git config branch.foo.merge refs/heads/bar" "git config branch.foo.remot baz". Meaning when on branch 'foo', fetch branch 'bar' from remote 'baz'.	18:16
	s/fetch/pull/	18:16
	s/remot/remote/	18:16
wycats	can I use origin?	18:17
	branch.foo.remote origin?	18:17
Ilari	wycats: What makes you think that it is any way special except for being default in some cases?	18:17
wycats	I guess it's not ;)	18:18
Ilari	Yes, origin should work (if there is such remote defined)...	18:18
wycats	and refs/heads will work with pretty much any remote?	18:19
	refs/head/branchname?	18:19
Ilari	wycats: s/head/heads/, otherwise yes. Branches are stored inside refs/heads/...	18:19
wycats	and that'll work for git push as well?	18:20
	or do I still need git push origin <branchname>	18:20
Ilari	wycats: 'git push' IIRC takes remote to use from branch.foo.remote, but is unaffected by branch.foo.merge...	18:21
	wycats: But once you have pushed that branch, then 'git push' should push it.	18:21
wycats	cool	18:22
Ilari	wycats: 'git push foo bar' or 'git push foo --all' is only required to push branches for the first time.	18:22
wycats	so git push foo --all the first time	18:23
	subsequently git push foo	18:23
Ilari	wycats: IIRC, If you have set up branch.foo.remote and have already pushed, you can push current branch with just 'git push'. AFAIK, 'git push foo' means push to remote foo...	18:26
wycats	k	18:26
madduck	why do i want denyNonFastForwards when I have multiple committers?	18:27
	i can't figure it out. i know the high-level theory about commits getting lost otherwise,	18:27
	but I can't figure out how that would happen.	18:27
Ilari	madduck: So nobody pushes things losing data lightly... There are people who try things and then add -f when they don't work...	18:28
	← dkagedal left	18:28
madduck	i don't understand...	18:29
Orangebat	Anyone have a script that will add all currently untracked files to .gitignore files in their directories?	18:29
gitte	madduck: it's not about commits getting lost. It's about forcing the other devs to merge. When they probably do not want to.	18:29
Ilari	Orangebat: In their directories, no, but 'git ls-files --others >>.gitignore' might work...	18:30
madduck	Orangebat: git-ls-files --others	18:30
gitte	Orangebat: how about "git ls-files --untracked > .gitignore"? ;-)	18:30
	Oops. --others.	18:30
madduck	gitte: i cannot find --untracked	18:30
	yeah..	18:30
gitte	Thanks, madduck	18:30
	→ Surma joined	18:30
gitte	And thanks Ilari: I'd overwrite .gitignore.	18:30
jrockway	hmm, am i delerious or did "git push origin foo:foo" used to create a foo branch remotely	18:30
	i don't remember ever typing ...:refs/heads/foo	18:31
	:)	18:31
gitte	No.	18:31
	git push origin foo did.	18:31
Ilari	gitte: After being burned by branches in SVN? :-)	18:31
Surma	Hey guys. Is there a way to prevent git-commit from nagging about trailing whitespaces?	18:31
gitte	Ilari: I avoid SVN where possible, so I was only burnt once, when I could not undo an erroneous commit...	18:31
jrockway	Surma: remove the trailing whitespace :)	18:31
Orangebat	Thanks guys. I had the '--others' solution, but was looking for a way to move then in to their local directories	18:32
jrockway	Surma: git warns because that can screw up your history (git blame) needlessly later	18:32
	→ nud joined	18:32
	← alley_cat left	18:35
	← meandtheshell left	18:39
	→ alley_cat joined	18:40
	← Surma left	18:43
Ilari	gitte: What, SVN doesn't have equivalent of 'git revert HEAD*?	18:43
madduck	git-clone does not work when the source repo has no commits	18:43
	but when you pass -s, it does work	18:43
gitte	Ilari: what do I know... ;-P	18:44
madduck	but does not set up a remote tracking branch unless the URL starts with <schema>:// or /	18:44
	→ mneisen joined	18:44
madduck	is that a bug?	18:44
gitte	madduck: yes. In you repo ;-)	18:44
madduck	how so?	18:45
	why does using -s allow an empty HEADless repo to be cloned?	18:45
	and why does the remote tracking branch depend on an absolute url?	18:45
	→ Ken\|JLime joined	18:46
Ken\|JLime	I moved my git repository to a new server and want to be able to give rights to a group. Ive set the core.sharedRepository = true, but how can I state the group I want access... AND update the repository so all file permissions are reflected?	18:47
	If possible I would like to avoid creating a new git repository only to have that working	18:47
	← Timotheo left	18:48
cehteh	some manual tinkering with umasks, permissions (sgid, writeable) etc then it will work	18:49
gitte	madduck: you did not really clone the empty repo. And that -s works is most likely a bug.	18:50
	madduck: to say "clone an empty repo" is as saying: I have a vacuum here in my lab, which is an exact copy of the vacuum somewhere at the end of the universe.	18:50
madduck	right, i understand that much	18:51
	so the -s is a bug...	18:51
	gitte: but wouldn't it be nice to be able to clone an empty repo just to have the remotes set up right away?	18:51
Ilari	Ken\|JLime: Do recursive setting of at least following permissions for direcories: u+rwx and g+rwxs, plus chgrp all directories in repo to apporiate group.	18:51
Ken\|JLime	Ilari, oki thanx	18:52
Ilari	Ken\|JLime: And ensure that files have g+r set...	18:52
Ken\|JLime	roger	18:52
Ilari	Ken\|JLime: Plus of course all files should be chgrp'd.	18:52
gitte	madduck: personally, I find empty repos utterly uninteresting. And I will not even waste time setting up a local "clone" until the remote side has something to show.	18:54
Ilari	Ken\|JLime: Standard Unix permissions stuff, execpt that sharedRepostory thing (it forces group permissions on new files to match user permissions, overriding umask).	18:55
madduck	gitte: fair enough, but...	18:55
	i am sure you saw http://blog.madduck.net/vcs/2007.07.11_publishing-git-repositories	18:55
	all this is necessary because I can't just do:	18:56
	one my public git server: GIT_DIR=/path/to/dir.git git --bare init --shared	18:56
Ken\|JLime	Oki, big thanx	18:56
madduck	on my laptop: git clone ssh://.../dir.git; cd dir; make changes; git add .; git commit; git push	18:56
	gitte: it would just be easier. that's all.	18:57
Ken\|JLime	If I use shared will all pushes have same group as the original file?	18:58
Ilari	Ken\|JLime: Setgid bit on directories causes all files created to be implicitly "chgrped" to that group.	18:59
Ken\|JLime	oki thx	18:59
gitte	madduck: if you make a good case, you might succeed with a patch that makes "git clone" on empty repos succeed.	19:00
madduck	gitte: yeah, i might have to have a shot at that. if only i had more time.	19:02
	i have another thing i cannot figure out	19:02
	can i make git-pull fetch from two remotes and merge them octopus into master?	19:02
	i tried branch.master.remote=. and branch.master.merge='refs/heads/remotes/A/master refs/heads/remotes/B/master'	19:03
	but that does not work.	19:03
Randal	set up an alias?	19:03
	or a script?	19:03
madduck	well, yeah.	19:03
	i was more wondering if i could make git-pull do it automatically	19:03
Randal	git-fetch remote1; git-fetch remote2; git-merge remote1 remote2	19:03
	I can't imagine needing to do that on a routine basis	19:04
	what's your workflow that results in that?	19:04
madduck	i work on proj from office with someone in another city, push my stuff to public repo as i leave, the person also pushes, and when i get home, i just want to git-pull and get both changes	19:05
Randal	they push into a different repo?	19:05
madduck	yeah	19:05
	we pull from each other	19:05
Randal	sounds rare enough that a script would probably be teh right way	19:05
	I can't imagine modifying core utils to do that	19:05
	in fact, why aren't you rebasing instead of merging?	19:06
	just fetch both before you go	19:06
	then rebase your new changes on top of that	19:06
	in general, unless you have published, you should be rebasing	19:07
gitte	And why not do that independently of another? You don't need an ugly octopus.	19:07
Randal	leave the seafood to Linus. :)	19:07
Mikachu	surely your home repo should always be a fast-forward of your office repo?	19:07
	← chris2 left	19:08
Randal	that too	19:08
gitte	Randal: AFAIK Linus detested octopus merges from day 1.	19:08
Randal	well - someone added them. :)	19:08
Mikachu	i like this one http://mikachu.ath.cx/thatsonewaytodoit.png	19:09
	→ engla joined	19:09
gitte	Randal: that was our good maintainer, Junio.	19:09
Ilari	gitte: Wasn't the original rationale: "Many respectable SCMs can't represent them.", or something like that?	19:09
	→ jrmuizel joined	19:10
gitte	No I think it was more: "does not reflect the way we work".	19:10
Randal	You say that like tehre's also a bad maintainer. :)	19:10
gitte	And "is hard to resolve when there are conflicts"	19:10
	And "is ugly to look at"	19:10
	And... I'll stop here.	19:10
	← twilight\ left	19:11
madduck	Randal: i know what rebasing it, i can imagine what the advantages are, but I don't see why it's so much better than merging	19:11
gitte	Randal: No, I say this because I think we have a darned good maintainer.	19:11
Randal	ok	19:11
	← Pistahh left	19:11
	→ Pistahh joined	19:11
gitte	madduck: did you look at the link Mikachu sent?	19:11
madduck	gitte: thanks, looking...	19:11
gitte	It's totally confusing.	19:11
gitster	Itari is correct there and it was not like "detested the octopus merges from day 1" AFAIR.	19:11
gitte	madduck: With rebasing, you pretend a linear workflow... which is much nicer to look at, and much nicer to work with.	19:12
	gitster: my memory goes bad I think.	19:12
madduck	but you should nt be rebasing if you publish the branch, right?	19:12
Ilari	It doesn't appear to be that "the merge from hell". That thing has 12 parents (the merge depicted has only 8).	19:12
	gitte did too much work for the day job.	19:12
madduck	or should you not be rebasing when you push the branch to the same repo that has the branch onto which you're rebasing?	19:12
gitte	madduck: you can rebase _before_ publishing.	19:12
madduck	hm.	19:13
Randal	in fact, that's the normal way	19:13
gitte	Ilari: but that's from Russel King...	19:13
Randal	other wise, why have rebasing	19:13
madduck	so i branch off master and do my work. master is updated so i fetch it and rebase on top of master	19:13
Randal	if you never published a rebased branch, you're not contributing. :)	19:13
madduck	i then publish my branch (A)	19:13
gitte	madduck: exactly.	19:13
	← alley_cat left	19:13
Mikachu	gitte: i was just scrolling through the linux log a week or so after i started using git	19:13
madduck	now what happens if master updates and i make changes to A?	19:13
gitster	Ilari: Hell 12 one was from Len.	19:13
Randal	you fetch and rebase again	19:13
	repeat every time	19:14
	rebase before publishing	19:14
madduck	so i can publish a branch i have rebased in the end?	19:14
Randal	indeed!	19:14
	otherwise, as I said, rebasing would be useles	19:14
madduck	so what would be a case when you should not rebase?	19:14
Randal	just don't rewrite any commits that you've already published	19:14
gitster	Randal: Yeah, I think the recent topic of "pull --magic-option" = "fetch + rebase" instead of "pull = fetch + merge" would have a use case there.	19:14
madduck	Mikachu, gitte: that link, it's two octopus merges, right?	19:14
	gitte is off for an hour or two...	19:15
madduck	Randal: but when i rebase a branch, don't i rewrite all commits?	19:15
gitte	madduck: no, it is just one.	19:15
Randal	arguably been off for a lot longer than that. :)	19:15
Mikachu	madduck: only the ones since the common ancestor	19:15
madduck	gitte: one by russell, one by linus...	19:15
gitte	gitster: basically, this is the workflow by _non_ maintainers...	19:15
madduck	Mikachu: ic...	19:15
Mikachu	madduck: linus' is just a regular merge	19:15
gitte	madduck: no, the first is a simple merge.	19:16
madduck	true, now i see it.	19:16
	→ alley_cat joined	19:16
gitte	madduck: it just crosses so many lines.	19:16
Mikachu	you can just read the short log too :)	19:16
gitte	It's an ugly viewer.	19:16
	gitte is really off now.	19:16
	→ jerbear joined	19:16
Mikachu	i had some trouble setting a nice font in gitk in the beginning	19:16
	← Pieter left	19:16
Mikachu	had to edit the ~/rc file to make it not bold	19:16
Ilari	Reminds me of 2 000 way octopus I did for testing purposes... Back then git-commit-tree overflowed buffer if there was more than 16 parents and I was running the hacked version so there was a lot of space to overrun without hitting anything important.	19:16
Mikachu	besides i like qgit over gitk still :)	19:16
	(but not qgit2)	19:17
madduck	so bear with me for another example about this, it'll be a bit longer	19:18
	mdadm upstream is in git; i track it as upstream/master, merged into local upstream branch	19:18
	off upstream, i branched debiandir for debianisation	19:18
	i branched upstream-patches off upstream for patches i submit upstream, and i also branched two deb-only/{A,B} branches for stuff only for debian	19:19
	when i make a release of mdadm for debian, i rebase master onto upstream	19:19
tko	sigh I did it again.. pushed only not master branch to remote and new clones fail :-(	19:19
madduck	and if i make any changes to debiandir (like increment the version), i then merge debiandir into master?	19:20
Randal	that should be a fast-forward	19:20
	or not. confused now.	19:21
madduck	me too. :)	19:21
vmiklos	huh, it seem to be a bit overcomplicated to me :) but maybe i'm wrong	19:21
madduck	vmiklos: my workflow?	19:21
vmiklos	yes	19:21
madduck	how would you do it?	19:21
vmiklos	i would just have upstream, origin and my local branches. then i would push my patches to origin and cherry-pick the needed ones to a separate branch when i want to submit them	19:22
madduck	okay, but i actually publish my local branches on git.debian.org	19:23
vmiklos	yes, origin is git.debian.org	19:23
madduck	right	19:23
	can we walk through this?	19:23
	so i pull upstream and i branch debiandir off	19:24
	make all the debian-specific stuff happen there	19:24
	push debiandir to origin	19:24
	and now you're saying that to make a release, i tag debiandir (and upstream, maybe)	19:24
	→ evan joined	19:24
madduck	create a throwaway branch	19:24
evan	is there a reason that 'git stash apply' doesn't delete the stash?	19:24
madduck	off upstream	19:25
jrmuizel	anyone know of good way to have a default commit template for a repository?	19:25
madduck	cherry-pick debiandir into there	19:25
	→ rodserling joined	19:25
madduck	make deb and delete the branch?	19:25
tko	hmm.. I just cloned a repo over http and I only see the HEAD branch.. what am I missing?	19:25
Mikachu	tko: branch -r?	19:25
madduck	tko: git branch -r ?	19:25
Mikachu	(tko: hi)	19:25
tko	indeed..	19:25
madduck	MadCoder: are you listening in?	19:26
vmiklos	madduck hm. i would fetch, then rebase master to upstream/master. then cherry-pick the needed patches to a feature branch, finally push the local branches to origin. once the topic branches are merged, you can remove them. it seem to be simpler to me (of course your method is right, just maybe you can save some work :) )	19:26
madduck	cherry-pick seems more work than merge...	19:27
vmiklos	how many patches do you submit after a relase? avarage 0 or 1? :) - i assume	19:27
madduck	nah, it could be more.	19:27
	plus, i'd like to keep things within debiandir separated	19:28
vmiklos	aren't those patches independent from upstream releases?	19:28
madduck	the debian ones, yes.	19:28
	not the ones i have in upstream-patches	19:28
vmiklos	no, i mean the 'for-upstream' ones	19:28
madduck	well, usually upstream will have them merged by the time the next release comes around.	19:28
albertito	evan: I don't know, but a friend just ran into git troubles and that saved a lot of work =)	19:28
evan	albertito: hm, good to know.	19:28
	albertito: i find it odd that the only way to remove stashs is to delete them all.	19:29
	→ Pieter joined	19:29
madduck	evan: stash is supposed to be temporary	19:29
albertito	evan: so if there is no real reason to delete them, I think it's nice to keep them around just in case	19:29
madduck	evan: if you use it often, you should be using branches instead.	19:29
vmiklos	you can have an alias like 'stashapply' that would stash apply && stash clear	19:29
evan	madduck: oh, i agree.	19:29
	i'm automatting some workflow stuff for developers	19:29
	i suppose i shouldn't worry if they have stashs	19:30
madduck	vmiklos: if i made a short demo repo, would you have the time to look at it?	19:30
	or anyone else?	19:30
evan	i'll just stash; fix; apply; clear	19:30
madduck	vmiklos: or actually, i'll write it up, i think	19:30
vmiklos	madduck sure :) not that i would be better in git than you, just more eyes can catch more bugs:)	19:31
madduck	k, but this is going to take a while, so i might have to ping you again tomorrow or even later	19:31
vmiklos	that's okay, no rush	19:32
evan	whats the best way to find out the name of the current branch?	19:38
	there must be something better than 'git branch \| grep "*"'	19:38
madduck	git branch \| grep '^\*'	19:38
	:)	19:38
Mikachu	git-name-rev HEAD	19:38
evan	git branch needs another option then	19:38
	git branch -o	19:38
	or something.	19:39
	up_the_irons → irons\|lunch	19:39
evan	Mikachu: close, but still extra stuff is output.	19:39
Mikachu	only one line with two words	19:39
	and the first is always HEAD	19:39
evan	true	19:39
	← alley_cat left	19:40
	→ alley_cat joined	19:41
	→ DrNick joined	19:43
madduck	so, uh, if i want to prepare a patch, I branch off the master branch, right?	19:49
	netx and pu are used by junio to cherry-pick/stage stuff for testing, right?	19:49
gitster	Not really.	19:50
MadCoder	madduck: I wasn't	19:50
	damn, is d. kastrup joking with -Oprofile ?	19:50
madduck	MadCoder: no worries, i am writing something up and i shall send it to you for comments anyhow.	19:51
	← wolf^ left	19:51
madduck	gitster: i cannot find that document where you explain the branches	19:54
	and the SubmittingPatches doc does not mention it either	19:54
gitster	madduck: I probably should update MaintNotes (posted after 'master' release as "Note from maintainer" on the list) in the todo branch; could you read it over and tell me what part needs clarification please?	19:55
MadCoder	madduck: usually if it's a fix for the stable branch for a big bug (think RC ;p) it's to be done on top of master	19:55
	else base it on top of next	19:56
madduck	ok	19:56
	gitster: yes, i will do that. you mean the list post?	19:56
	MadCoder: so since i am proposing a feature, i would thus branch off next...	19:56
gitster	Either should be fine. I think MaintNotes in the todo branch is up-to-date now with the one posted to the list the last time.	19:56
	But the short version is this.	19:57
	maint and master are the primary "release" branches.	19:57
	Anything new that I need to think about for more than 5 minutes will _not_ get committed on these branches.	19:57
	← Orangebat left	19:57
gitster	Instead, (1) if it is a bugfix that applies to the last 4-digit release (maintenance), a new topic branch is created off of 'maint' and committed there; (2) otherwise a new topic branch is created off of 'master'.	19:58
madduck	i am proposing to let git-clone clone empty HEADless repos simply because then the remotes are all set up and i can easily push to it	19:58
	http://colabti.de/irclogger/irclogger_log/git?date=2007-10-03,Wed&sel=621#l1055	19:58
	it's not necessary at all, just makes things simpler	19:58
gitster	Then, the tip of the topic branch is merged to 'next' iff it is in testable shape (does not have obvious breakages and risk breaking things too badly for people who run 'next' version).	19:59
	The fixups will be done on top of each topic branches and merged to 'next' number of times, until the topic is perfected, at which time it is merged to 'master' or 'maint' depending on where it came from.	20:00
	The tip of 'maint is also merged to 'master' from time to time.	20:00
madduck	and there seems to be a bug because git-clone -s already allows empty repos to be cloned.	20:00
gitster	We could detect and forbid that if we really wanted to be consistent but I'd say why bother. Cloning nothingness is a user error anyway.	20:01
	In any case, what follows the branch management policy outlined above are:	20:01
madduck	except for the use case when i know from a start that i want to create a new repo that i want published	20:01
	on my public git server: GIT_DIR=/path/to/dir.git git --bare init --shared; on my laptop: git clone ssh://.../dir.git; cd dir; make changes; git add .; git commit; git push	20:02
	would just be easier than http://blog.madduck.net/vcs/2007.07.11_publishing-git-repositories	20:02
gitster	(0) a fix that applies to the released four-digit version should be made against 'maint';	20:02
	(1) a fix or enhancement that does not depend on anything that is still cooking on 'next' should be made against 'master';	20:02
	→ nessundorma joined	20:03
gitster	(2) an enhancement or a fix to a topic that is cooking on 'next' can be made against 'next' and have me sort it out, or alternatively you can "git log --first-parent next" to see where the tip of the topic branch you are fixing or enhancing is, and create a patch against that commit (and tell me that you did so); the latter would save me a lot of time if the topic can textually interact with other topics simultaneously cooking in	20:04
	'next';	20:04
	Ken\|JLime → Kristoffer	20:06
madduck	ok, i shall read the doc with this in mind	20:06
	probably next weekend though	20:07
gitster	take your time. I won't be gitting the coming weekend.	20:08
madduck	gitster: what do you say about the cloning empty repos	20:09
	should i bother writing up a patch or just keep a local script...	20:09
Arjen	I'm curious if someone has an explanation to the question I asked earlier: http://colabti.de/irclogger/irclogger_log/git?date=2007-10-03,Wed&sel=250#l473	20:11
gitster	What I say does not count as much as how others find it useful. I _suspect_ it is not worth it, but I've known to be wrong. You can push into an empty repository and you will be pushing into that repository many times from then on for publishing, so it would be good thing to make it easier to do that one time setting of "where do I push and how" would be a good thing but I do not think "cloning from void" is the way to do it.	20:12
	Is the "user's survey" still going on? Maybe we should take down the notice...	20:12
madduck	gitster: good point.	20:12
	gitster changed the topic to: 1.5.3.4 \| Homepage http://git.or.cz/ \| Everyone asleep or clueless? Try [email@hidden.address] \| Channel log http://colabti.de/irclogger/irclogger_log/git \| Mailing list archives: http://marc.info/?l=git \| Gits on git: http://tinyurl.com/2xq3ke \| You want $ID?: http://tinyurl.com/yqpgv9 \| User's Survey 2007 http://tinyurl.com/26774s	20:13
madduck	Arjen: no idea, sorry.	20:14
	→ jcollie joined	20:16
	← evan left	20:16
	← wycats left	20:17
	← branstrom left	20:18
	→ branstrom joined	20:18
gitster	blame works harder and "git log" (git in general -- blame is just for fun and analysis) is not really interested in individual files.	20:19
	The output of "log -p" is meant to be consumed by traditional patch so it does not even do any file renames by default. If you give -M to ask it to look for rename, it will notice "ah, entire file A came from entire file B that disappeared", and say "rename B to A". There is no provision to say "concatenate B and C to create A".	20:21
	irons\|lunch → up_the_irons	20:22
gitster	So you can say the inconsistency is deliberate. "log" is aiming towards producing something patch can apply (rename patch you can edit the headers to have rename-unaware GNU patch to apply, but that would become almost impossible if you do "concatenate" patch format).	20:23
	Does that answer the question?	20:24
Arjen	Yes, but I have another one :-)	20:24
	Uh no, I have to play around a bit more for that one :-)	20:25
	When a chunk of code move from 'multiple' places to a new one, is it possible (with current git) to show all the sources?	20:30
	s/move/is moved/	20:31
	← alley_cat left	20:31
	→ REPLeffect joined	20:31
	→ csc`` joined	20:34
	→ alley_cat joined	20:35
vmiklos	you mean ie when foo() is moved from foo.c to common.c and bar() is moved from bar.c to common.c in the same commit?	20:35
Arjen	No, when an identical piece of code is removed from foo.c and bar.c to common.c (a refactoring)	20:36
	← metafollic left	20:36
	→ metafollic joined	20:40
	→ troyt joined	20:40
	← mneisen left	20:40
	← engla left	20:40
	→ nud_ joined	20:41
	← nud left	20:41
troyt	Quick question: When I build git RPMs, I get an error about a failed dependancy: perl(Error) is needed by <foo>. What is the perl(Error) generally packaged with?	20:41
	→ tcoppi_ joined	20:43
	← tcoppi left	20:44
	← nessundorma left	20:44
	← branstrom left	20:45
	tcoppi_ → tcoppi	20:45
	← csc` left	20:45
	← tcoppi left	20:45
	→ tcoppi joined	20:46
	→ branstrom joined	20:46
fonseca	krh: Yes, the stuff about leaving things sounds good. In fact that will be required by stuff like git-archive (which need to to also parse format specific options).	20:46
	krh: So do you have some code for this? If you have feel free to send me ...	20:47
MadCoder	I didn't read the list very carfully	20:51
	fonseca: you wrote an option parsing module ?	20:51
	→ dduncan joined	20:51
	→ kristoffer_ joined	20:52
	← alley_cat left	20:52
	Mikachu wouldn't mind if -ab was accepted as -a -b	20:52
HackyKid	+1	20:52
MadCoder	that looks interesting, but if we are going to use such a thing (which I believe is good because many builtins have more code in the option code than the rest) it should be able to deal with git diff's options that are kind of awkward	20:52
	Mikachu, HackyKid: oh yeah	20:53
	I'm pissed by the git rm -rf	20:53
	I mean, my finger can't type rm -r -f	20:53
	it's just too hard for'em	20:53
	but it's not what the patch is about afaict	20:53
krh	fonseca: I have, I just converted builtin-add as a test	20:53
MadCoder	hmm it seems I'm the devil today	20:56
	(http://www.ohloh.net/accounts/8822)	20:56
	→ alley_cat joined	20:57
MadCoder	oh no krh is the one writing the module	20:58
	csc`` → csc`	20:58
MadCoder	krh: did you had a look at git diff options ?	20:59
krh	MadCoder: yeah, I have an updated version here the incorporates fonsecas feedback from the list	20:59
	MadCoder: no, I haven't looked at git diff yet	20:59
	I'm looking at git log now	20:59
MadCoder	okay, because git diff is the one with the most awkward command line switches in git I think	20:59
krh	yeah... there's not a lot of consistency	21:00
MadCoder	builtin-grep too	21:00
Mikachu	one wonders why -u is a synonym for -p and -U is --unified	21:00
MadCoder	krh: I've not followed closely, but does your patches has chances to be accepted ?	21:01
Mikachu	too many lolcats today?	21:01
krh	MadCoder: I hope so :)	21:01
MadCoder	because I would be interested from a janitoring PoV to migrate most of git onto the new model	21:01
krh	for now it's just saving me a lot of lines in builtin-commit	21:01
MadCoder	okay	21:01
	well, most of the easy builtins have 60% of the code in the option parsing loop	21:01
krh	also, builtin-add: 21 insertions(+), 43 deletions(-)	21:02
MadCoder	I'm not surprised at all	21:02
krh	nope, it's a low-hanging fruit	21:02
MadCoder	krh: does your code supports one letter flags aggregation ?	21:02
	à la rm -rf	21:02
krh	MadCoder: not yet, but it's not hard to do	21:02
MadCoder	i guess so, I'm just asking if it works that's all	21:03
	because it's one of the most irritating thing :)	21:03
	← Kristoffer left	21:03
MadCoder	krh: anyways I'd say that if your module works nice with grep and diff, then it's ready for git	21:04
	← jerbear left	21:04
	← lcapitulino left	21:04
krh	MadCoder: let me look at grep	21:04
MadCoder	grep option parsing is like 200 lines	21:04
	(it's in builtin-grep.c)	21:04
	and diff'one is in diff.c: (diff_opt_parse)	21:05
	and it's "just" 139 lines	21:05
	but grep is harder I believe	21:05
	it does quite a lot of stuff	21:05
	diff is just a whole lot of options, but with very few side effects, should be easy in fact	21:06
	(except for the sometimes awkward argument passing to some flags, but I believe it's easy in fact)	21:06
Mikachu	does your "library" do more git-specific stuff than getopt would?	21:06
krh	MadCoder: what's tricky is that sometimes '--long-option' means "use default value" and '--long-option=value' means use value	21:06
	and sometimes '--long-options' means "use next argument as value	21:06
MadCoder	yeah	21:06
gitster	FWIW, I do not think anybody minds if the new parser suddenly start accepting "-S string" instead of saying "Ah, look for a string with length 0 and then what is that 'string' about???".	21:07
MadCoder	Mikachu: well I've always wondered why git didn't used getopt_long in the first place	21:07
	but I suppose that it's not very portable	21:07
gitster	No, most of the options to C did not even have to be human typable.	21:08
MadCoder	(and I've always thought that getopt_long has a very crappy interface btw)	21:08
gitster	As in "plumbing is only to be used by Porcelain scripts, never by humans".	21:08
MadCoder	makes sense at the time I suppose	21:08
	*made	21:08
gitster	We had some discussion quite some time ago, which I suspect was before any of the people who spoke in the last 20 minutes here started reading the list, and liked popt over getopt_long.	21:09
MadCoder	well I read the list for 1.5 years already	21:09
Mikachu	i still don't :)	21:09
MadCoder	but assiduously for only a couple of months	21:10
	gitster: and the conclusion was ?	21:10
	oh popt is better, I don't know popt	21:10
	← moh left	21:10
gitster	I am not saying "we _should_ because we already decided"; I am just saying we should look at it if we are going to do this for real this time.	21:11
	← mithro left	21:12
gitster	It might turn out that getopt() is more suitable. We did not go that far the last round. I do not think the guy who tried last time far enough to start designing how to deal with what revisions and diff parsers do (i.e. parse their own stuff, leave the rest to other people).	21:13
	→ rlb3_work joined	21:13
	→ moh joined	21:13
gitster	s/far enough/went &/	21:13
	← Dodji left	21:14
	→ engla joined	21:16
MadCoder	I see	21:17
gitster	I'll try that size_t stuff.	21:18
MadCoder	gitster: what I meant on the list is that on linux size_t is an unsigned long, though nothing in C makes that a hard rule, hence when you ask for -pedantic it will trigger errors	21:19
	← felipec left	21:19
	→ doublec joined	21:20
	← nud_ left	21:25
	→ mithro joined	21:29
MadCoder	gitster: it seems that on win64 size_t is 64 bits wide	21:29
	though long is still an unsigned int	21:30
	so s/unsigned long/size_t/ will help a possible win64 git port :)	21:30
	(at least it's the information I seem to have gathered, it's not first hand)	21:30
	→ strangy joined	21:32
	→ drizzd_ joined	21:35
	← jcollie left	21:41
	← alley_cat left	21:43
	jwb → jwb_gone	21:44
	← HackyKid left	21:46
	← drizzd left	21:48
	← troyt left	21:49
	← loops left	21:53
	→ loops joined	21:55
	← mithro left	21:57
	← ferdy left	21:58
	← Teln1100A left	21:59
	← orospakr left	22:00
	← kristoffer_ left	22:04
	← krawek left	22:07
gitster	geez. this is a lot of code churn...	22:09
	← drizzd_ left	22:14
gitte	gitster: what code do you mean?	22:15
gitster	what I have in my emacs buffer.	22:15
gitte	Ah, I don't know about that.	22:16
gitster	yeah, I do not run vnc server here for you to peek ;-)	22:16
MadCoder	too bad	22:16
Mikachu	would be interesting to watch at times	22:16
gitte	ATM I would not understand anything anyway.	22:17
MadCoder	and that wouldn't be the funniest part of you running vnc anyways	22:17
	the "let's inject random keyboard and mouse event" sounds like way more fun	22:17
Mikachu	i would maybe run with -viewonly	22:17
	← krh left	22:19
	← Ryback_ left	22:20
	→ agoode joined	22:23
	→ grahal joined	22:29
	← Oejet left	22:29
	← elmex left	22:33
	→ myrizio joined	22:34
mutex	so when using the git-merge tool, it shows you three files... 'LOCAL' <file path> 'REMOTE'	22:36
	I assume REMOTE is origin	22:36
MadCoder	LOCAL is your branch	22:36
	REMOTE is what you try to merge into your branch	22:37
	and the other is the current state of what you are melding	22:37
mutex	and file path is the current file contents ?	22:37
	ok	22:37
	so due to some wonkiness I obvious have a conflict	22:37
	do I need to merge in order to push the current file state up to both local and origin ?	22:38
	→ jtoy joined	22:38
mutex	or can I do something special to fix it all	22:38
	I must admit part of my problem is I am not clear on how vimdiff works	22:38
	→ joeyh joined	22:38
joeyh	hello, I'm having some trouble with git-clone --shallow	22:39
	I seem to only get shallow clones if I clone from a remote repo. Cloning locally doesn't produce a shallow clone	22:39
gitster	file:///	22:39
joeyh	does that just force -l off?	22:40
	← grahal left	22:40
gitster	it makes a repository that resides on the same host as if it is accessed over the network.	22:40
	s/host as if/host look as if/	22:41
joeyh	ok, works	22:42
	thanks, madduck said you were a helpful guy	22:42
gitster	well I cannot resist helping somebody called joeyh if you are who I think you are (although /whois is very unhelpful). Thanks for your work on Deb.	22:43
joeyh	yes, I'm me	22:44
GyrosGeier	hehe	22:44
MadCoder	he is who he is	22:44
joeyh	yipes, what happened to my whois info	22:44
	not on freenode much	22:44
MadCoder	a tiny perl script ate it	22:44
GyrosGeier	resistance is futile. You will be packaged for Debian and are doomed to spend a few months in NEW.	22:44
MadCoder	heh	22:44
GyrosGeier	how many DDs are in here now?	22:45
MadCoder	too many	22:45
GyrosGeier	dammit	22:45
	if I give keithp his T-shirt now it will be like "meh."	22:45
joeyh	well, while I'm here..	22:45
MadCoder	GyrosGeier: ?	22:46
GyrosGeier	MadCoder, I planned to make "keithp is a git fanboy" T-shirts for DC6 and distribute them to people before his talk	22:46
MadCoder	heh	22:46
GyrosGeier	but the T-Shirt order fell through with the print shop	22:47
MadCoder	:/	22:47
	you meant DC7 I assume ?	22:47
GyrosGeier	no, Mexico	22:47
MadCoder	oh, he's in git for that long …	22:47
GyrosGeier	yep	22:47
	← engla left	22:47
MadCoder	funny, he hasn't a lot of patches though	22:49
gitster	Who?	22:49
MadCoder	keithp	22:49
	Keith Packard	22:49
	our organ repairman	22:50
gitster	Yeah, not from the code standpoint there has been NO contribution, but x.org together with wine made git accepted outside of the kernel and keith is responsible for the newbie cries we hear recently around here and on the list.	22:50
	← gitte left	22:50
MadCoder	yeah	22:51
	and he wrote parsecvs too	22:51
gitster	without his (in)famous blog post, we wouldn't have this much visibility now.	22:51
MadCoder	hmmm I'm catching up with djpig	22:51
	gitster: which one ?	22:51
gitster	Hmph. 2k line of patch. It does not look _too_ bad as I initially feared.	22:52
MadCoder	gitster: the size_t thingy ?	22:52
gitster	Yes.	22:52
	There are a few issues that needs careful review.	22:52
joeyh	dpkg-source: building dpkg in dpkg_1.14.7.git.tar.gz	22:53
	dpkg-source: building dpkg in dpkg_1.14.7.dsc	22:53
	joey@kodama:~/tmp>grep Format dpkg/debian/control	22:53
	Format: 3.0 (git)	22:53
gitster	(1) printf "%lu", sz --> "%"PRIuMAX", (uintmax_t)sz; the compiler would help us catch it.	22:53
joeyh	-rw-r--r-- 1 joey joey 3.1M Oct 3 18:52 dpkg_1.14.7.git.tar.gz	22:53
	:-)	22:53
gitster	(2) "unsigned long" is used at least three ways. (2-a) size_t; (2-b) time_t; (2-c) uint32_t.	22:53
MadCoder	gitster: sz does not exists on msys	22:54
	I mean %zu	22:54
joeyh	wow, that's actually smaller than the regular dpkg source tarball	22:54
MadCoder	oh right the PRIuMAX horror	22:54
	← REPLeffect left	22:54
MadCoder	joeyh: yes, it's obvious that you're still new to git :)	22:54
	← strangy left	22:54
MadCoder	and you can remove the .gz part	22:54
gitster	I do not want to touch (2-b) this round, and (2-c) we should not touch ever (they are "file formats" and used after htonl()).	22:54
MadCoder	right	22:55
	why would we like to touch 2b ?	22:55
	joeyh: the _full_ glibc history in a git tree is 100Mb	22:55
	it's actually a third of the checkout size	22:55
gitster	If we _do_ mean time_t, we should be using that type, but we are not currently.	22:55
MadCoder	and it goes back in 1992 or sth like that	22:55
	gitster: oooh, I see, you mean sometimes ulong is used to store time_t's	22:56
	sorry I didn't groked in the first place	22:56
GyrosGeier	joeyh, BTW have you talked to Scott James Remnant about pristine-upstream?	22:56
gitster	So I probably should split this into (1/2) PRIuMAX with (uintmax_t) cast; and (2/2) s/ulong/size_t/.	22:56
GyrosGeier	joeyh, I believe he talked about something like that in the context of launchpad in Helsinki	22:56
joeyh	GyrosGeier: no, but it's working quite near 100%.	22:56
	I've re-watched his talk, afaik it never got released	22:57
GyrosGeier	ah so you are at least aware of it	22:57
joeyh	sure, I was in the room ...	22:57
MadCoder	gitster: otoh we could spare (uintmax_t) casts	22:57
joeyh	and was the one who asked about it then ..	22:57
MadCoder	that could be a PRI_SZ	22:58
	GyrosGeier slept through most of it after playing Mao the night before until it was dark, only to be awaken by the first sunlight	22:58
MadCoder	that would be a make configuration variable	22:58
	on any linux and bsd %zu will work	22:58
joeyh	I seem pretty asleep too in the video	22:58
MadCoder	(I wonder if it isn't even C99)	22:58
	yes %zu is C99	23:01
GyrosGeier	we should use C++ and iostreams to solve that problem	23:02
MadCoder	gitster: so I would avoid the casts and use a custom PRIuSZ macro that would expand to zu on C99 platforms	23:02
	GyrosGeier hides	23:02
MadCoder	gitster: and let people "fix" the definition in the Makefile like any other for systems that don't have the C99 zu according to the proper size_t width on their platform	23:03
	casts are sooo ugly	23:03
	(and intmax_t is C99 too afaict)	23:03
	so I think my way is more portable	23:03
	← robinr left	23:03
GyrosGeier	MadCoder, would PRIuSZ be just the "%zu", or the entire printf statement?	23:03
MadCoder	no it's zu	23:04
	I modelled it after PRIuMAX or PRIuLEAST32 or ...	23:04
	that is supposed to be used like that:	23:04
	"%-02.12"PRIuMAX"...."	23:04
GyrosGeier	yuck.	23:05
MadCoder	(for obvious reasons you don't want the % to be included)	23:05
	you said it	23:05
	← cmarcelo left	23:05
MadCoder	be relieved to know there is the same SCN* shit for scanf formats	23:05
GyrosGeier	I maintain uclibc	23:06
MadCoder	C99 § 7.8.1.3	23:06
	I maintain glibc	23:06
	I win	23:06
	:P	23:06
GyrosGeier	when I make the uclibc packages support all this, people yell at me that I should shrink the library	23:06
MadCoder	well _this_ does not makes the library big	23:06
	those are supposed to be macros	23:06
GyrosGeier	%sz and so on	23:06
MadCoder	you mean zu	23:07
GyrosGeier	whatever.	23:07
	:-)	23:07
MadCoder	z is a "length" modifier like l, ll and so on	23:07
GyrosGeier	this is one of the rare occasions where C++ code is really a lot smaller	23:07
	because you only pull in those printing routines that you actually use	23:07
MadCoder	if those are defined in separate compilation units	23:08
GyrosGeier	-ffunction-sections -Wl,--gc-sections	23:08
MadCoder	which is a gccism ;)	23:09
GyrosGeier	yep	23:09
	MSVC does that by default	23:09
	icc probably finds out the unreachable bits in the printf function from looking at the format strings	23:10
	rumour has it that it will achieve sentience next year	23:10
	well	23:10
	good thing this doesn't matter for git	23:10
	because when I have memory for a repo, I have memory for a full printf with 30kB	23:11
	which reminds me	23:11
	joeyh, would it make sense to teach ikiwiki a special mode where page edits are committed to new branches?	23:12
	that could be used as a CMS	23:12
	anyone can submit changes, and some editor would merge them	23:12
joeyh	sure, there's some requests about having a way to queue and review changes, it could be done	23:12
MadCoder	CMS ? GyrosGeier you're talking funny :p	23:13
	← GyrosGeier left	23:13
	→ GyrosGeier joined	23:13
MadCoder	:)	23:13
GyrosGeier	sorry	23:13
	Machine BSODed on me just after sending the last sentence	23:13
	← Yuuhi left	23:14
	→ gitte joined	23:14
	← loops left	23:16
madduck	joeyh: i actually said gitte was extremly helpful, but gitster (who is the git maintainer) has also never let me down. :)	23:18
	→ dash__ joined	23:21
	← GyrosGeier left	23:26
	→ GyrosGeier joined	23:26
GyrosGeier	argh	23:26
	again.	23:27
madduck	Mikachu: so i don't unde3rstand the rebasing thing after all...	23:29
	← KirinDave left	23:30
madduck	i clone a repo from upstream	23:30
	committed three changes	23:30
	popushed them to my public repo	23:30
	pushed	23:30
	upstream pulled them	23:30
GyrosGeier	madduck, then you don't need to rebase	23:30
madduck	and committed some more	23:30
	i fetched upstream	23:30
GyrosGeier	madduck, that is a normal merge	23:31
madduck	GyrosGeier: true...	23:31
	so what should i do now?	23:31
	merge off upstream again?	23:31
GyrosGeier	madduck, if upstream pulled and merged your stuff, upstream version is a descendant of your version	23:31
	so you can fast-forward	23:32
	→ KirinDave joined	23:32
GyrosGeier	if you have more commits that upstream didn't pull, you can rebase last_version_upstream_saw..HEAD onto upstream	23:32
madduck	so wait	23:32
GyrosGeier	i.e. rebase is only good for things noone else has seen so far	23:33
madduck	actually, upstream did not commit anything	23:33
GyrosGeier	because it rewrites history	23:33
madduck	GyrosGeier: that's not what Mikachu said earlier	23:33
	so upstream did not merge any of my changes	23:33
GyrosGeier	then you can rebase, and upstream needs to force-pull	23:33
madduck	see http://scratch.madduck.net/__tmp__ss.png	23:33
	← dash_ left	23:33
tpope	yeah sorry	23:34
GyrosGeier	tpope rebased your stuff instead of merging it	23:34
madduck	http://colabti.de/irclogger/irclogger_log/git?date=2007-10-03,Wed&sel=697#l1158	23:34
	this is my repo.	23:34
	tpope: no problem, i am learning.. :)	23:35
tpope	actually I just completely disregarded it :)	23:35
madduck	which is fine for now...	23:35
tpope	I decided not to merge when I changed names to gitmail	23:35
	then I changed back to getsendemail anyways	23:35
madduck	GyrosGeier: so it holds, i pushed my branch	23:35
	then rebased now after what Mikachu said (which I probably misunderstood)	23:35
	and now of course the commits have different IDs and I cannot fast-forward	23:36
GyrosGeier	madduck, if you rebase your branch, you end up with a history similar to tpope's	23:36
	I /think/ it should be the same	23:36
madduck	GyrosGeier: yeah, but my remotes/origin/master is useless.	23:36
GyrosGeier	but I'm not sure about the commit dates	23:36
	yes	23:36
tsuna	gitster: So do I rewrite my NO_RPATH thing with the function-like LINKER_RPATH (despite the problem you mentioned with old GNU make) or not?	23:37
GyrosGeier	madduck, why did you commit into an origin branch anyway?	23:37
madduck	GyrosGeier: huh?	23:37
	so then i don't understand why i would ever rebase any branch that i had already published.	23:37
	what's an origin branch?	23:38
GyrosGeier	you have the branches in the origin/ directory	23:38
	that are for pulling only	23:38
	you never commit to them	23:38
tsuna	for fetching only	23:38
	pulling = fetch + merge	23:38
GyrosGeier	instead, you create your own local branch and work on that	23:38
	and that is what you publish	23:39
madduck	i did not commit to remote branches	23:39
	i fetched tpope's stuff into master	23:39
	then committed onto master	23:39
	then pushed my master	23:39
	now tpope updated without my commits	23:39
	and i fetch his stuff	23:39
	now i could merge that into my master	23:39
	but i wanted to try rebasing	23:40
	but i should never rebase a branch that i had published, right?	23:40
tsuna	right	23:40
	→ loops joined	23:40
madduck	then i really wonder what i misunderstood earlier	23:40
	GyrosGeier needs to reboot	23:41
madduck	which means now in terms of debian packaging, i will always merge since i publish my debian packaging on git.debian.org	23:41
	tsuna needs to sleep	23:41
GyrosGeier	WGA wants to scan me, or something.	23:41
madduck	unless i am working on a feature branch that i have not pushed anywhere	23:41
GyrosGeier	damn Windows crap.	23:41
madduck	then i can rebase to resume work	23:41
gitte	GyrosGeier: use a proper OS ;-)	23:41
GyrosGeier	I try	23:41
	if it weren't 2 AM on the day after a national holiday, I'd use the term "day job" as an excuse	23:42
	right now, it's more like a "night job"	23:42
tpope	well let me follow up madduck's question with another	23:42
tsuna	what national holiday?	23:42
madduck	i think i just misunderstood Mikachu.	23:42
	tsuna: german unification	23:42
GyrosGeier	brb	23:42
	← GyrosGeier left	23:42
tsuna	ah OK. Forgive my ignorance.	23:43
tpope	I implemented the functionality madduck did independently	23:43
	so essentially, the changes in his branch should be discarded	23:43
	what's the proper way to do that?	23:43
	if he merges he will have conflicts	23:44
madduck	i branch again of your tip	23:44
tsuna	git reset --hard to remove the commits you want to get rid of?	23:44
madduck	and i leave my branch untouched forever.	23:44
tpope	--hard, --mixed, and --soft still confuse me	23:44
madduck	tsuna: i never did that commit, but yes, that's a way to undo a merge	23:44
	tpope: --hard == index and worktree, --soft is just index	23:44
	i never used --mixed	23:44
tpope	which is strangely enough the default	23:45
madduck	be careful with git reset is all i can say. :)	23:45
tsuna	tpope: --hard removes something from the repo entirely, --soft and --mixed are similar, they're used to reset changes in your index and working copy (kinda like svn revert)	23:45
madduck	tpope: but if you want to undo the last commit and you have not published it,	23:46
	git reset --hard HEAD^	23:46
	→ GyrosGeier joined	23:46
GyrosGeier	re	23:46
tsuna	Actually if you git reset --hard something, I think you can still reach the commit with git fsck (it will show a dangling commit?) or via reflogs	23:46
	← bdiego left	23:46
tpope	okay, it's starting to make sense	23:46
tsuna	But once you do git gc, it's gone gone gone.	23:47
tpope	I've read through much of the manual but it's a lot to absorb	23:47
tsuna	Yes, it takes a little while.	23:47
gitte	MadCoder: the lack of %whatever on MSys is not a problem; we'll just add a define...	23:47
MadCoder	gitte: yes, I'm not afraid	23:48
tpope	okay madduck, to clarify what you said earlier, would you git branch -d master; git checkout -b master origin?	23:49
gitster	I am, it is just a massive code churn that needs to be carefully audited.	23:49
	← jackbravo left	23:49
madduck	tpope: i would probably git checkout -b new-master origin/master	23:49
	tpope: but instead, i think i'll just discard my master branch, yes.	23:49
	git push origin :master	23:50
MadCoder	gitster: :)	23:50
madduck	git checkout -b new-master origin/master	23:50
	git branch -m master old-master	23:50
tpope	push will try to merge though wouldn't it?	23:50
madduck	git branch -m new-master master	23:50
MadCoder	no	23:50
	push never merges anything	23:50
tpope	errr	23:50
madduck	tpope: push :branch deletes branch	23:50
tpope	I said push but read pull	23:50
madduck	remotely	23:50
MadCoder	anyways I'm off to bed	23:50
tpope	and thoroughly confused myself	23:50
madduck	bon nuit	23:50
gitte	gitster: All I wanted to say is that the lacking formats on MSys should not be the culprit of not accepting that patch.	23:50
MadCoder	gitster: good luck with you rulongs	23:50
madduck	bonne nuit even	23:50
MadCoder	gitte: otoh he's the one writing it, so … ;)	23:51
gitte	MadCoder: I know; I was talking from the view point of a reviewer.	23:51
MadCoder	the concern I had is that gitster was talking about using "%"PRIuMAX ..., (intmax_t)l which I find ugly because of the macro _and_ because of the cast	23:51
	(with l being a size_t of course)	23:52
	oh okay	23:52
madduck	gitster: re the cloning empty repos, what would you think about 'git-init --origin url://to/remote/git', which then simply adds the remote and sets up a merge for master?	23:52
GyrosGeier	argh	23:52
gitte	madduck: I'm not familiar with that patch, but if it is the only correct thing, ugliness be damned.	23:53
madduck	gitte: ?	23:53
gitte	Oops: madcoder, not madduck	23:53
madduck	aha.	23:53
gitte	Too many mads here.	23:53
MadCoder	gitte: it's the thing gitster launched a thread about	23:53
	he wants to replace unsigned longs with size_t where appropriate	23:53
	and it generates the issue of printf's	23:54
gitte	MadCoder: I saw the thread, but lack the time to review it.	23:54
MadCoder	and it happens that C99 has %zu	23:54
	so I proposed on IRC to avoid the cast, and have a PRI_SZ defined as zu on C99 enabled compilers	23:54
	and the proper u/lu/llu on the other	23:54
	that was merely it	23:55
	madduck: yeah bonne nuit is better btw	23:55
mutex	I think I've been doing bad things with git and now my setup is broken	23:55
MadCoder	Gute Nacht ;)	23:55
	mutex: are you deadlocked ?	23:56
	(SCNR)	23:56
mutex	my git-cvsexportcommit keeps complaining about not being able to apply patches	23:56
	heh	23:57
	no... not dealocked ;-)	23:57
gitte	Just a guess: your git branch is not uptodate?	23:59
mutex	no I think its more complicated	23:59
gitte	I.e. you did not rebase your changes on top of the most recent cvsimport?	23:59
mutex	but my problem may be that I set this all up wrong	23:59

Logs Search ←Prev date Next date→

Channels Documentation