IRCloggy #git 2007-04-27

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-04-27
pasky	[Fri Apr 27 02:04:51 2007] [error] [client 62.24.88.241] usage: git-rev-list [OPTION] <commit-id>... [ -- paths... ], referer: http://repo.or.cz/	00:03
aeruder_	are you using git version of gitweb?	00:12
pasky	omg	00:14
	pasky bangs his head at the wall	00:14
	pasky forgot to make install :))	00:14
aeruder_	hehe	00:14
	works now :)	00:15
pasky	yeah.. :)	00:15
gitster	Ah, I was trying it out myself if there was any obvious breakages. Good that it was something so trivial.	00:20
pasky	why do we include HEAD in git-ls-remote output for native protocols but not for HTTP repos?	00:37
aeruder_	i think the correct answer may be that http support is the red-headed stepchild ;)	00:39
	→ jonesy joined	00:46
tcoppi	is there any way to get `git-ls-tree -s` to not output the sha1 hash?	01:06
mugwump	--name-only ? :)	01:08
	wait, -s ?	01:08
tcoppi	yeah, -s	01:08
	err, eait	01:09
	wait	01:09
	git-ls-files	01:09
	that makes more sense :)	01:09
mugwump	--abbrev=0 ? :)	01:11
	no, that doesn't work	01:12
tcoppi	yeah, tried that	01:12
	→ dinakar joined	01:15
dinakar	Hello	01:16
aeruder_	hey dinakar	01:17
dinakar	I downloaded git source to compile on AIX 5.2 and I am getting error in make configure	01:18
	it give there is problem with Makefile and states the line number	01:19
	I looked into Makefile but cannot find anything wrong	01:19
aeruder_	do you have gnu make?	01:20
	i'm not sure if git requires it, but its certainly possible	01:20
dinakar	Yeah I install make	01:20
aeruder_	is it gnu make?	01:20
	→ yashi joined	01:20
aeruder_	make --version	01:20
	should print out GNU Make <version>	01:21
	because the bsd make here fails horribly (unsurprisingly)	01:21
	sometimes it is installed as 'gnumake' or 'gmake'	01:22
	but typically a unix system would have 'make' being bsd make	01:22
	→ jasam joined	01:24
gitster	I am very sure git makefile pretty much depends on GNU make.	01:24
aeruder_	gitster: yea, it does very much so, just remembered i had it installed and it definitely does not work :)	01:25
	aeruder_ likes using the word 'it' 2-3 times in a sentence with not all the 'it's referring to the same thing	01:25
aeruder_	translation: git makefile definitely requires gnu make, bsdmake fails horribly on git's makefile :)	01:26
	→ dinakar_ joined	01:27
dinakar_	sorry aeruder_	01:27
	I will try to find GNU make and try it . Thanks for the information. I really appreciate it	01:28
aeruder_	dinakar_: you need gnu make, bsd make will not work (make --version should print GNU Make <version>), sometimes on unix machines gnu make is installed as gnumake or gmake	01:28
dinakar_	make --version says there is no option of --version	01:29
aeruder_	yea, so that's not gnu make ;)	01:29
	do you have 'gmake' or 'gnumake' ?	01:29
	if not http://ftp.gnu.org/pub/gnu/make/	01:30
dinakar_	thanks. I will to compile it if it gmake is not there. At present, I can not check. Thanks	01:30
aeruder_	ah, ok, good luck	01:30
dinakar_	Yesterday I installed on on cygwin and it worked fine so I thought I will start using on our development box	01:31
	thanks	01:31
	← dinakar_ left	01:32
	→ aroben joined	01:34
	→ rphillips_ joined	01:36
jasam	hi, I want to push a change I did to my repository in a new branch, and I don't know exactly what params I must to give git push to have that new branch in the remote repository and those changes on it: git push orcz my-branch-name? # (orcz is the alias for my remote repository)	01:40
	I don't know exactly how remote branches are created	01:40
	well, I will do some exercises in a local sandbox tomorrow, now I'll go to bed, bye!	01:49
	→ Gitzilla joined	02:01
	→ Romster joined	02:03
	Gitzilla has _finally_ caught up on almost 3 months of #git IRC logs and ML!	02:06
aeruder_	haha	02:06
	read the irc logs even? crazy ;)	02:07
DrNick	there's IRC logs?	02:07
Gitzilla	also noticed that ilogger2 has missed some periods.	02:07
	Check the topic.	02:08
DrNick	there's a topic :)	02:08
Gitzilla	We're all clueless?	02:09
aeruder_	man, makes me wish i hadn't bashed gitzilla all those times over the last few weeks	02:09
Gitzilla	Make it up w/ patches.	02:10
aeruder_	:)	02:10
	i've got a queue building up, just going to finish up a few more and send another chunk to the ml	02:11
	→ spearce joined	03:01
	→ aroben_ joined	03:22
	→ aroben joined	03:25
	→ aroben joined	03:35
	→ orospakr joined	03:36
	→ agoode joined	03:36
aeruder_	pasky: very cool (grep patch to gitweb)	03:50
spearce	yea, that snippet of ident.c is one of my favorite corners of git...	03:52
	→ orospakr_ joined	03:55
aeruder_	spearce: hehe :)	03:58
	spearce: could i get your opinion on a bit of documentation?	03:59
spearce	sure	03:59
aeruder_	http://dump.aeruder.net/local-fetch.patch.txt	04:00
	seem cohesive? :)	04:01
spearce	yes, looks good to me.	04:01
	i didn't know these options existed. ;-)	04:01
aeruder_	hey, that's what i'm here for	04:02
	hehe	04:02
	i'm over 60 commands in on the great discover-undocumented-command-line-options adventure	04:02
spearce	hah	04:02
	→ jeffpc joined	04:02
	→ rkaway joined	04:27
gitster	Who uses local-fetch these days, though...	04:30
	shawn, still here? Ack on git-mirror Pasky edition?	04:31
spearce	there's a bug in the docs. i'll send a message to list in a minute.	04:32
aeruder_	gitster: oh well, if they need it, it'll have the documented options ;)	04:33
gitster	well, documentation updates are always appreciated, and especially the kind you are doing, going over everything, as it sheds light to otherwise neglected corners.	04:35
	We might end up realizing this and that are not used and deprecating them, but that is probably a good thing, too.	04:36
aeruder_	yea, i'm not opposed to that, i'm just attempting to get the documentation up to the standards of what is currently in the code	04:36
	and hopefully future code changes will take care of the changes (whether removing or adding)	04:36
gitster	date; TZ=UTC0 date; TZ=Pacific/Kiritimati date	04:38
	oops, sorry, wrong window.	04:38
spearce	hah	04:38
aeruder_	hehe :)	04:38
pasky	gitster: I actually really have no idea whether git-mirror isn't mostly redundant with allt eh cool "new" (<0.5y old) git-fetc features.. :)	04:39
	but I'm too sleepy now	04:39
	g'nite	04:39
gitster	Except removing stale refs, refs/:refs/ should be equivalent these days, I would say.	04:39
spearce	fetch = +refs/heads/:refs/heads/; git remote prune ;-)	04:39
gitster	That probably is "+refs/:refs/", but except that, yeah.	04:40
	Does "remote prune" actually work? I've never run it myself.	04:40
spearce	yea, i use it all the time.	04:40
aeruder_	man, i need to stop attempting to use git-send-email, its too freaking dangerous!!	04:42
	:)	04:42
gitster	Well, so it is either adding a howto/ to describe how to use fetch for mirror, or add git-mirror itself. I have a feeling that reusing fetch might be less learning for people, but I dunno. Either way, I can drop one item from the todo:TODO.	04:42
spearce	yea, now that you point it out, there's probably not a huge need for git-mirror as fetch can do everything except switching the HEAD symref.	04:42
gitster	I've been trying to use send-email using myself as a guinea pig. I've killed small glitches myself, but haven't seen any major breakage myself. What's dangerous?	04:43
	Anyway, I think we will do rc1 with what I pushed out last night on 'master', plus merge-recursive tweak from Alex and post-receive-email updates from Andy and nothing else.	04:45
aeruder_	gitster: eh, i just tend to forget that it automatically adds the Cc:'s from author/signed off	04:46
	:) and then my testing accidentally goes all over the place (especially if i forgot the --dry-run option)	04:46
	:)	04:46
gitster	Ah, I use a wrapper script myself anyway, so that is not a problem for me, but I guess there should be a config option to tweak its behaviour.	04:47
aeruder_	nah, not a big deal, just i'll stick to format-patch dumping a mbox and then i'll manually send them :)	04:47
gitster	For example, my wrapper script sets --from, --no-chain-reply-to, --to, --suppress-from, --no-signed-off-cc, --smtp-server.	04:47
aeruder_	its less dangerous for me :)	04:48
gitster	I think --from, --suppress-from --smtp-server are personal preference,	04:48
aeruder_	yea	04:48
gitster	--no-chain-reply-to, --to and --no-signed-off-cc are probably per project.	04:48
	So as long as send-email can read from $HOME/.gitconfig and .git/config, I do not have to have the stupid wrapper script. Maybe it already does.	04:49
spearce	gitster: re: rc2 i might have some small git-gui stuff this weekend that might be nice to have in 1.5.2.	04:49
gitster	That's fine; rc1 is not the end of the world ;-) It is just "Ok, no more new features or patches we haven't seen on the list already".	04:50
spearce	:)	04:50
gitster	And that won't happen for at least a few days. Maybe I'll do that Monday.	04:50
	I started to send some e-mails (not patches) to git-list using send-email; it felt somewhat funny, though.	04:51
aeruder_	hehe	04:51
aroben	is there any way to find the root of a git tree without crawling upwards and looking for the .git folder?	04:52
spearce	git rev-parse --show-cdup	04:52
	wait, no, there's another flag that's better.	04:53
gitster	That crawls upwards and looks for the .git directory.	04:53
	→ Romster joined	04:53
gitster	"git rev-parse --git-dir" perhaps?	04:53
spearce	yea, that. ;-)	04:53
gitster	But that crawls up.	04:53
aroben	gitster: spearce: good enough for me. Thanks!	04:53
spearce	well, it depends on what aroben wanted. if he meant him writing code to crawl up and find the root, rev-parse is better.	04:53
aroben	spearce: exactly	04:54
gitster	I was just trying to be funny, but I was not successful.	04:54
spearce	:)	04:54
	its difficult to be funny on this timewasting device. :)	04:54
	aeruder_ shuts his eyes tight and uses git-send-email	04:59
aeruder_	oh god, please work	05:00
	→ robin joined	05:00
spearce	looks like it did.	05:10
aeruder_	no, it didn't, i got a reply from david miller telling me the emails were messed up and rejected, so i'm mutt'ing them up :)	05:10
spearce	i got 1/8...	05:11
aeruder_	the other 7 just got sent, i haven't found a good way to do mutt + replying to the first one	05:11
spearce	i don't bother.	05:11
	spearce is a mutt user.	05:11
aeruder_	so i generate the whole series with format-patch once, send the first message, grab the message-id from it when it hits the list, and then i redo the format-patch with --in-reply-to and send those	05:12
	spearce: yea, i remember that :)	05:12
gitster	What I've been doing is to format using 'format-patch -n', prepare 0000-cover.txt file by hand, mimicking 0001-patch-name.txt file, and send the whole series ;-).	05:15
	No --in-reply-to nonsense is needed by doing that.	05:16
aeruder_	do you bother with threadifying your patch series?	05:16
	looks like not, maybe i should stop bothering, if its not going to be a pain on anyone on the list	05:16
gitster	I think I _could_ --chain-reply-to, and some people on the list seem to prefer it.	05:16
	I personally do not care.	05:17
robin	I like 'em threaded	05:17
	→ devogon joined	05:17
aeruder_	yea, git-send-email would work well for that, just need to figure out what all went wrong with it	05:17
robin	aeruder_: The "Removing -n option from git-diff-files documentation" etc?	05:19
aeruder_	i don't know if you can teach mutt to leave the Message-ID alone	05:19
	robin: yea	05:19
robin	they are kind-o-threaded here	05:20
gitster	2-8 are replies to 1.	05:20
robin	that's ok with me	05:20
aeruder_	yea, that's what i intended, but it was a royal pain in the butt to do :)	05:20
robin	as long as they belong to the same thread	05:20
aeruder_	i need a better system	05:20
gitster	I like that style, although some people seem to prefer 3 to be reply to 2, 4 to be reply to 3 etc.	05:20
	I find 0000-cover.txt trick easy enough ;-)	05:21
	aeruder_ checks out mutt git to see if a quick hack could make it not touch Message-ID: when its in the message	05:21
robin	what's better is to have the series as a reply to a cover message	05:21
aeruder_	robin: yea, but my cover message was several days ago and i just figured gitster already knows what all my patches are for, so why bother ;)	05:22
robin	have a "flat" thread I think is better wrt to comments from others	05:22
	aeruder_: not just gitster reads patches	05:22
aeruder_	robin: i know, but still, the theme is quite apparent	05:23
	even from just the subjects	05:23
gitster	Andrew, have you actually formatted these into html/man and checked the format?	05:23
aeruder_	gitster: you referring to the git-blame patch?	05:23
gitster	-L with continued paragraphs with '+', yes.	05:23
aeruder_	http://dump.aeruder.net/git-blame2.png	05:24
	that's what it looks like	05:24
	in html form, its...	05:25
gitster	Thanks. I just wanted to make sure you have already done the checking (which would make my double-checking lower priority).	05:25
aeruder_	gitster: yea, i haven't been double checking the html as much	05:25
	i'll show you the html for that one as its the only halfway complex one	05:25
	http://dump.aeruder.net/git-blame3.png	05:26
	hm, not sure why it colors it differently	05:26
gitster	I suspect if you do not indent lines after '+' continuation they would come out nicer.	05:26
aeruder_	let me try	05:27
	aeruder_ finally made himself a sweet git-fix-commit command	05:27
aeruder_	hehe	05:27
gitster	Hmm. http-fetch was not written by Linus (not your fault). Do we want to fix the attribution fix at some point, I wonder...	05:28
aeruder_	gitster: want me to fix that while I'm at it?	05:28
	gitster: ah, you're right, without the indentation it looks much better	05:30
gitster	Yeah, one of unexplained irritation of asciidoc.	05:30
	I believe http-fetch was originally by Dan Barkalow and Nick Hengeveld gets a lot of credit for it too..	05:30
	→ sgrimm joined	05:32
gitster	Probably somebody would want to write a script to postprocess "blame -C" output and come up with weighting. like 30% to Barkalow, 60% to Nick, etc ;-).	05:32
	By the way, tonight's 8-patch series seem to apply all to 'maint'. I've been applying your patches all to 'maint' as we haven't changed much since 1.5.1.	05:34
	→ robfitz joined	05:34
aeruder_	oh, ok, fwiw, all the changes are actually against origin/master	05:34
gitster	If you have further patches, and if some of them talk about new features only available on 'master', it would be nice if you can somehow mark it as such, although I'll try to be careful, too, on my end.	05:35
aeruder_	oh, yea, sorry, i guess i didn't think about that	05:35
gitster	Nothing to feel sorry about.	05:35
aeruder_	so would it be better if i made all the patches against maint (and checked maint commands for new options?)	05:36
	s/new/undocumented/	05:36
gitster	Strictly speaking 'maint' is bugfix only -- I happen to feel that missing documentation is a documentation bug, so have been trying to see if your documentation updates apply to both or only to 'master' and applied the ones that apply to both to 'maint' to be merged into 'master'.	05:36
	If in an ideal world, I would prefer:	05:37
	(1) a patch series to apply to 'maint', to fix the missing/incorrect description that is in 'master' and 'maint';	05:37
	(2) another series, that would apply to the state of 'master' that results from merging 'maint' with all of (1).	05:38
	But I know that is too much to ask for contributors, so I typically shuffle patches myself to make that happen.	05:39
aeruder_	how about i'll continue doing it against origin/master but when i document a new option, i'll just double check to make sure it wasn't added since maint, and if so, i'll make a note on the patch	05:39
	will that work for you?	05:40
gitster	That's fine. By the way, if you do not have anything other than that "no-indent" on the blame -L patch, I'll fix it here and apply (i.e. no need for resend).	05:40
aeruder_	oh, good deal	05:40
	yea, if you just remove the initial indent on the parts between +'s it gets rid of the html coloring	05:41
gitster	Monospace font is more annoying than coloring.	05:41
aeruder_	nah, its not monospace	05:41
	or are you saying the old one was? i guess i didn't notice	05:42
gitster	I was talking about git-blame3.png we saw earlier.	05:42
aeruder_	ah, ok	05:43
	yea, i only noticed the coloring on that one, whoops :)	05:43
	but yea, the coloring and monospace are gone by removing indentation on those 3 paras	05:43
	gitster: file=http-fetch.c ; git blame -C $file \| sed -e 's/[^(](//; s/ [0-9][0-9][0-9].//' \| sort \| uniq -c \| while read line ; do nums=$(echo "$line" \| cut -d' ' -f1) ; echo $line "($(((100 ${nums}) / $(wc -l < $file)))%)" ; done	05:45
	550 Nick Hengeveld (51%)	05:45
	165 Daniel Barkalow (15%)	05:45
	hehe	05:45
	go me!!	05:46
	a '\| sort -n' goes well on the end	05:46
gitster	We may want to use the same .mailmap git-shortlog uses. I think Daniel appears under different names.	05:48
	→ Roomster joined	05:48
aeruder_	ah, you're right	05:48
	108 [email@hidden.address] (10%)	05:48
gitster	For consistency, I think it is better to be done in pretty_print_commit() in commit.c, but I am hesitant to have such a "fixup" hook too close to the low-level object layer.	05:49
	But at least "git blame" itself should know how to make use of .mailmap, perhaps as an optional feature.	05:50
	It should not be forcing your postprocessing to do that.	05:50
aeruder_	yea, i'll add that on my little todo list, that'd be good to have	05:51
	but for now, i sleep, i'll fix up that http-fetch patch tomorrow if you haven't for the real authors	05:54
	git has been causing some major sleep shortages lately ;)	05:54
	→ pdmef joined	06:24
	→ ferdy joined	07:16
	→ sgrimm joined	07:21
	→ spearce_ joined	07:34
	→ gitte joined	08:07
	→ Roomster joined	08:19
	Roomster → Romster	08:51
	→ nud_ joined	08:52
	← dduncan left	08:52
	→ gitte joined	08:55
	→ quag joined	08:57
quag	hi	09:01
gitte	wHi	09:01
gitster	wHi? and good night.	09:11
quag	:)	09:12
	I'm getting some weird diffs. Looks like lines have been merged/mangled. Does this sound familar?	09:13
	and format-patch giving output like:	09:15
	+++ b/libs/iovm/source/IoFile.h	09:15
	@@ -92,6 +92,7 @@ IoObject IoFile_readBufferOfLength_(IoFile self, IoObject locals, IoMessage	09:15
	is this a known problem?	09:16
nud_	quag: it looks just like diff -p	09:18
quag	oh	09:18
	so git apply should be able to apply the patch?	09:18
nud_	it's not weird at all it's just to make the diff more readable	09:18
	patch -p1 is able to apply it	09:19
quag	thanks	09:19
	hehe, I can be dumb sometimes :)	09:19
nud_	the only difference is that you have the current function name on the @@..;@@ line	09:19
Tali	quag: yes, it should just work	09:19
quag	ah, looks like the patch has been line wrapped too :)	09:21
nud_	that's an editor issue then	09:22
quag	nud_: yup :)	09:24
	thanks guys	09:26
	→ chris2 joined	09:32
gitte	gitster: just a case of fat fingers.	09:36
ferdy	gitster: I could sort mails in the Maildir without parsing them using the mtime field. But it seems a bit fragile, what do you think ?	09:36
gitte	What do the docs say?	09:36
ferdy	(the Maildir spec sais that the mtime is the time that mail arrived to the Maildir, so acording to the spec, using it is sane)	09:36
	I'm afraid about two patches arriving at the very same time and getting sorted the wrong way though... not sure how likely that is	09:37
gitte	But is it precise enough? Remember, Git is _really_ fast. So, if the maildir thing was generated somehow by Git, chances are that several patches share the same mtime.	09:37
	Also, external mail often arrives in wrong order.	09:38
ferdy	now, the Maildir has to be 'generated' by a mail client	09:38
gitte	For example, the set of nine patches recently sent to the list came here as 1, 5, 4, ...	09:39
ferdy	and if the mail client changed those mtimes then they'd be on the same second... mutt definitely isn't changing them	09:39
	yeah... just drop the patch, I'll forget about Maildirs, there is no sane way, unless I started parsing References: and friends	09:40
	which would complicate the code a lot for no real good reason	09:41
gitte	But should that not be relatively fast? You can close the file as soon as you got that header...	09:41
ferdy	but when I got 2 mails that reference the same one.. I'll have to go with subject and/or Date: parsing	09:43
	s/got/get/	09:43
gitte	Hm.	09:43
ferdy	the patch series from Andrew Ruder, for instance, they all have References: [email@hidden.address] which is the first patch (1/8)	09:44
	so If I see two mails that reference the same, next thing is sorting by [PATCH N/M], date sorting is still racy	09:46
gitte	Right.	09:47
	BUT there are things people put in, like [PATCH (for pu) N/M], because the Subject is meant for human consumption.	09:48
	So I agree that it is a hard problem, conceptually.	09:48
	How do we solve it with mailboxes anyway?	09:49
ferdy	read sequentially	09:49
	since appending is the only sane way of writting to a mbox, it all works nicely	09:49
	now, If you copied the emails in wrong order (which is not very likely) you'd get them wrong	09:50
gitte	Right. And we cannot do that with Maildir, since it _is_ possible that the filesystem order does not reflect the copy order.	09:51
	gitte states the obvious.	09:51
ferdy	I'm starting to think that using Maildirs for that particular use case is not that good idea, since you don't really need the kind of advantages Maildirs give you (no locking + read what you need)	09:53
gitte	But then, some mail apps use Maildir natively, and it would be convenient to use that format.	09:54
	gitte goes and looks how Pine+maildir does it.	09:54
gitte	I _think_ Pine+maildir gives the mails names which sort in the order of arrival.	09:57
ferdy	the maildir 'spec' (not really a spec but what its designer wrote) states that you cannot rely on that	09:58
gitte	Well, if it works in reality, I do not care about specs.	09:58
	How does mutt do it?	09:58
ferdy	uses time(NULL) + getpid() + Counter++	10:02
	→ hein joined	10:02
gitte	So, sorting by name should really be sufficient!	10:03
ferdy	hrm... looks like	10:04
	what I'm afraid of is someone losing time because he relied on it working and I his tool didn't write mails with sort'able names :P	10:04
gitte	Why make _his_ problem _your_ problem?	10:06
	Of course, we should make sure that all major maildir apps use a sortable filename.	10:07
	But then, we're fine.	10:07
	gitte goes drinking some coffee.	10:07
ferdy	gitte: thats a good argument, I'll look into filename sorting, will add a big fat warning to the documentation	10:08
	hein → Sho_	10:18
	→ tango_ joined	10:28
tango_	hello again. I must say that I'm rather confused about branches, especially when it comes to syncronization with (truly) remote repository	10:29
	so say that I have my master branch which I use to sync with the 'upstream' remote repository. then I create a new branch (locally), and I want to have this branch upstream too	10:30
	I have two options now: either keep the local master as the 'upstream' for my branch, or have an upstream branch to push to. however, I'm not sure how to configure git to do either, and the only information I found seem to rever to older version of gits, and I'm not sure how to replicate those settings to 1.5	10:34
	→ etnt joined	10:44
	rkaway → rambokid	10:52
pigeon	is there a way to set it up so that when i git push, it automatically updates the working copy of the remote repo as well?	10:59
	pasky gives git remote update documentation a puzzled stare	11:03
gitte	pigeon: there's all kinds of weird problems you can get with that.	11:04
	But IIRC there has been a post-update hook posted to the list which does that.	11:04
	You'd have to install that on the remote side.	11:04
pasky	cogito has it in contrib/ ;)	11:04
gitte	tango_: I do not understand. The remotes/ name space is meant for remote refs...	11:04
pigeon	hmm ok	11:05
gitte	So, to track a remote branch you'd have copies of them in remotes/<remote-nick>/<remote-branch>	11:05
pasky	http://repo.or.cz/w/cogito.git?a=blob;f=contrib/push-update.sh;h=8b94ccf2f6187756c897e7ee41692505d6c05184;hb=HEAD	11:05
tango_	gitte, there is no remote branch yet	11:05
	there's a local branch which I want to push to remote as a new branch	11:05
pasky	pigeon: ^	11:05
pigeon	thanks	11:06
gitte	tango_: just push with "git push <remote> master other-branch"	11:06
	This will push both "master" and "other-branch" to the remote.	11:06
tango_	oh	11:06
pasky	pigeon: oh looks like it depends on cogito though :(	11:07
gitte	If you want to give them another name, use "git push <remote> master:upstream other-branch:rule-the-world"	11:07
tango_	gitte, what about if I'm on the other-branch currently? will git push push the branch to a branch or will it push the branch to remote master?	11:07
gitte	If you want to do that always (or almost always), you can do "git config remote.<remote>.push master:upstream other-branch:rule-the-world"	11:08
	and use "git push <remote>".	11:08
tango_	ok	11:08
gitte	tango_: git-push does not care about current branch.	11:08
tango_	this is what confuses me :D	11:08
gitte	If you do not have a "remote.<remote>.push" variable in the config, it will push _all_ branches which exist locally _and_ remotely.	11:08
tango_	hm	11:09
	oh	11:09
	but in branch "autodev" I see origin = .	11:09
	what does that mean?	11:09
gitte	It means that you branched "autodev" locally.	11:10
	This is the information what repo to pull from when none was specified.	11:10
tango_	ehm I mean remote = . obviously	11:10
	can I just set remote = "origin" and have it work automagically?	11:11
gitte	Yes, I interpolated that..	11:11
	Yes.	11:11
tango_	cool	11:11
	hm	11:11
gitte	You should also adapt branch.<name>.merge, obviously.	11:11
tango_	it says merge = refs/heads/master though	11:11
	ah	11:11
	so set it to refs/heads/autodev	11:11
gitte	Right!	11:11
tango_	cool	11:11
	tango_ is beginning to grasp it	11:12
gitte	That's good!	11:12
tango_	otherwise the branch gets pushed to master	11:12
	hm	11:12
	make sense, makes sense	11:12
	tango_ happy	11:12
gitte	No, branch.*.{remote,merge} are for pulling. Not pushing.	11:12
	s/gets pushed to/gets pulled from/	11:12
tango_	oh	11:12
	so remote = origin is for pushing	11:13
	what happens if remote = origin and merge = refs/heads/master?	11:13
gitte	However, I do not know off-hand if branch.<name>.remote is used for push...	11:13
	tango_ doesn't enquire for the moment, since this is an official xorg repo, and just goes for the sensible thing	11:13
gitte	I _think_ it's used.	11:13
	tango_ tries	11:15
tango_	hm	11:16
	didn't work	11:16
	it only pushed master	11:17
gitte	Does other-branch exist remotely?	11:17
tango_	no	11:17
gitte	If not, you have to tell push explicitely to push that branch.	11:17
tango_	oh	11:17
	→ Oejet joined	11:17
tango_	on the firs time only?	11:17
	hm	11:18
	oblomov@oblomov:~/gits/xorg/acecad$ git push autodev	11:18
	fatal: 'autodev': unable to chdir or not a git archive	11:18
gitte	Yes	11:19
tango_	git push --all	11:19
	?	11:20
	pasky reflects on his mails about git.or.cz and concludes that the situation about the homepage is the expectes "a lot of people whine but noone actually cares to do anything, or even talk about it"	11:20
gitte	tango_: Try git push origin autodev	11:20
	gitte thinks pasky is right; many people do not care enough.	11:20
gitte	pasky: I'd like to help, but I am a bit short on time.	11:21
tango_	aha, autodev head is there now	11:21
	→ GyrosGeier joined	11:21
	→ mountie joined	11:34
pasky	I'd actually be glad to just know how people feel about the points and questions I've raised	11:36
	that is, how the crash courses should look like etc.	11:36
	I think it's kinda important since for many people it's gonna be the first time they meet git	11:37
etnt	Hi, am I right in that I can use git and cg commands interchangeably ?	11:40
ferdy	if you mean that git blah == cg blah, then no	11:45
etnt	no, I mean that I can start e.g with running git-svn, run some cg commands, run some git commands, etc...	11:46
ferdy	I think they do some stuff differently, but pasky knows better :P	11:46
	pasky: wrt the mutt-sidebar Gentoo bug, upstream sees the problem as a PEBKAC... I think I'll just drop the patch, he refuses to fix it	11:48
	→ jasam joined	11:55
gitte	pasky: I did not even have time to read your mails properly...	12:02
dirker	When I did a git merge locally, I got a lot of unmerged files. Is there a nice way to keep track of which files have been merged and which haven't?	12:05
etnt	pasky: I'm new to git and cg and I have read a lot of info from the site, and enjoyed it :-)	12:06
dirker	(besides a grep for "<<<<<<" :))	12:06
gitte	dirker: I use "git add" on each conflicted file after I edited it. Then, "git ls-files --unmerged" or "git status" shows me which ones are left.	12:06
dirker	gitte: thanks	12:06
	etnt not sure what people have complained about though	12:06
gitte	dirker: You might also enjoy the new git-mergetool script...	12:06
ferdy	gitte: how about something like http://rafb.net/p/QopW5w59.html ? the patch is a bit big because of the linked list stuff	12:14
gitte	ferdy: sort_maildir() does not really sort anything, or does it?	12:19
	Hm. Maybe it is time to teach path_list about unsorted lists...	12:19
aeruder_	pasky: i'd like to go through the tutorials some when i'm done with the command docs	12:20
	win 4	12:20
	oops! :)	12:20
	win 4	12:20
	wow, my slash isn't working	12:20
	hehe	12:20
ferdy	gitte: it kind of does, list is sorted once sort_maildir is finished	12:20
	gitte: though the actual sorting is done in strlist_ins	12:20
gitte	ferdy: this will be shot down...	12:21
ferdy	ewww, why ?	12:21
gitte	O(N^2) instead of O(N log(n))	12:21
	Besides, we _do_ have path_list, which holds a sorted list of strings.	12:21
	(Would make your patch smaller, too)	12:21
ferdy	ouch... I didn't know	12:22
gitte	ferdy: Why take out the stdin check?	12:22
ferdy	gitte: it is still there	12:22
gitte	Ah. Moved to another hunk...	12:22
	s/to another/later in that/	12:23
ferdy	yeah, the diff is a bit misleading...	12:23
	I didn't want to go with the 'sort a big array' aproach because building it is way more expensive than building a sorted list	12:24
gitte	These issues, plus a typo: s/directories, it/directories why/	12:24
	ferdy: no.	12:24
	Sorting lists or arrays after the fact will always be cheaper than insertion sort	12:24
ferdy	well, building the array is what worried me	12:25
	not the actual sorting	12:25
gitte	What worries?	12:26
ferdy	lots of realloc's + memory waste	12:26
	though I can change it to qsort'ing a big array, it is much easier to code :>	12:26
gitte	ferdy: Just do #include "path-list.h" and stop worrying.	12:28
	jwb_gone → jwb	12:29
	→ lcapitulino joined	12:38
ferdy	gitte: ok, I used path_list this time: http://rafb.net/p/44soLV20.html	12:43
	will send it by mail later to make things easier if there are no obvious issues	12:43
	→ ilogger2 joined	16:17
	gitte feels logged again.	16:18
	→ tomprince joined	16:18
	→ ilogger2 joined	16:20
pasky	gitte: that lists 1.5.2-rc0	16:26
	instead of 1.5.1.2	16:26
	besides that it seems to be listed alphabetically by refname, which might theoretically produce bogus order	16:27
	pasky updated git in repo.or.cz's ssh jail, fwiw	16:29
gitte	pasky: right.	16:30
Randal	should I be using alt-git.git or git.git?	16:31
gitte	Randal: git.git is updated with the mirror script.	16:31
	alt-git.git is updated by Junio (when he thinks of it;-)	16:31
Randal	I don't know what that means	16:32
	can I just ask my questiona gain?	16:32
	or can you explain your two answers better?	16:32
gitte	It means that as long as Junio thinks of updating it, alt-git.git is more up-to-date.	16:32
pasky	git.git is mirror of kernel.org's git.git, but kernel.org can be flaky sometimes	16:32
	in that case, alt-git.git might have fresher git version	16:32
Randal	ok	16:32
	would git.git ever be more up to date?	16:32
pasky	(plus it doesn't support the mirroring delay which is normally up to one hour, but sometimes mirroring hangs for a few days until I notice ;)	16:33
	Randal: I don't know how regularily does Junio push to alt-git.git but if regularily, I think never	16:33
Randal	ok, I'll just keep pulling from alt	16:33
gitte	Wouldn't it make sense to give Junio push permission to git.git?	16:33
pasky	it would	16:33
	but he never asked for it :)	16:34
gitte	Then, git.git is as up-to-date as alt-git.git ever was.	16:34
	Okay, I'll ask then:	16:34
	gitster: Wouldn't you really want to push into git.git instead of alt-git.git on repo.or.cz?	16:34
	→ tomprinc1 joined	16:36
	lcapitulino discorvers git has a test-suite	16:50
pasky	:))	16:51
gitte	;-)	16:54
gitster	To answer Merlyn's earlier question. The order I do things is (1) push to kernel.org mirror source, (2) fetch what I pushed from kernel.org mirror source back to make sure the previous pushed what I wanted to push, (3) push what I got back in step 2 to alt-git.git at repo.or.cz	17:02
	It used to be that mirroring delay between time (1) and that hits public kernel.org machines were like 2 hours, and then git.git at repo.or.cz had polling delay from there, so definitely alt-git.git was the first public repo that you can see new things. I think mirroring delay at kernel.org from mirror source to public machines is much shorter these days, but probably the polling schedule at repo.or.cz still makes [email@hidden.address]	17:04
	niticeably behind.	17:04
	lcapitulino loves git-send-email	17:05
	pasky watches some evil robot crawling repo.or.cz	17:08
pasky	yay, three parallel snapshots of linux-mm.git requested	17:08
	pasky watches the machine cringe	17:08
	→ bronson joined	17:10
	→ aroben joined	17:15
	→ aroben_ joined	17:16
	→ aroben joined	17:17
	→ puzzles joined	17:18
aroben	pasky: yt?	17:18
pasky	?	17:25
	so git.or.cz will refresh latest git version number every 4 hours from now on	17:25
	→ robinr joined	17:26
pasky	[Fri Apr 27 19:26:20 2007] [error] [client 17.203.14.158] user aroben not found: /m/p/editproj.cgi, referer: http://repo.or.cz/	17:28
	nada :)	17:28
	aroben: can I help you anyhow?	17:28
	aroben: use the project name, not your username, to log in to the project admin section	17:28
aroben	pasky: yes, just a sec, phone	17:28
	pasky: ah, right, figured that out eventually last time I tried to do something :-)	17:28
	→ jeffpc joined	17:33
aroben	pasky: looks like I can't move aroben-git.git on my own?	17:33
	pasky: do you have to do that?	17:34
pasky	yep	17:35
	ah, that's you :)	17:35
aroben	pasky: go right ahead!	17:35
	pasky: yep :-)	17:35
pasky	ok	17:36
	done	17:36
aroben	pasky: great!	17:37
	pasky: repo.or.cz is a great service, btw	17:38
pasky	thanks	17:39
	→ dipplum joined	17:49
	→ tcoppi joined	17:56
	→ dipplum joined	17:57
	→ DrNick joined	17:58
	→ fultilt joined	18:14
	→ Eludias joined	18:18
jeffpc	pasky: you around?	18:35
pasky	yep	18:40
jeffpc	ah good	18:40
	I got an email telling me that a pull for guilt failed	18:40
pasky	when?	18:41
jeffpc	I don't remember my password to fix things up	18:41
	last night.. I think	18:41
	let me check	18:41
pasky	ah, never mind that one	18:42
jeffpc	2:49 CEST..	18:42
pasky	I've broken something at a bad moment :)	18:42
jeffpc	ok	18:42
	ah ok :)	18:42
cehteh	i got the same message from someone who runs mirroring from here ;)	18:46
	pasky: and i broke a mirror once but i am to dumb to fix it	18:46
	pasky: you removed the cinelerra repos?	18:47
pasky	did I?	18:48
cehteh	i cant see them	18:49
pasky	me neither	18:49
cehteh	maybe gitweb has some race .. sometimes happens here too that it misses some on display	18:50
	if you have some time please check /msg me .. i had some other issue too	18:50
pasky	I can't parse your sentence	18:52
cehteh	if(pasky==bored) message(cehteh) && fix_problem(cehteh);	18:53
pasky	would you rather push me the problem instead of having me pull it from you, please?	18:54
cehteh	sure .. i just didnt know if you are available to care for it :)	18:56
	so first ... whats happend to the cinelerra repos?	18:56
pasky	root@rover:/srv/git# ls -l cinelerra_cv.git/refs/heads/	18:56
	total 0	18:56
	this looks kind of funny	18:56
cehteh	strange .. ok can you completely delete them and delete any accounts associated with them	18:57
	then i initiate a complete new mirroring .. that the easiest and fixes the other problems too	18:57
pasky	that's the easiest but not good	18:57
	this shouldn't happen	18:57
	ever	18:57
cehteh	yeah sure	18:57
	we could investigate the problem before you go that far	18:58
pasky	git mirror git://git2.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git failed with error code 0	18:59
cehteh	mhm i got mailed for all my repos "update failed"	18:59
pasky	Log follows:	18:59
	warning: no common commits	18:59
	* refs/heads/master: storing branch 'master' of git://git2.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6	18:59
	commit: a205752	18:59
	fatal: insanely long action	18:59
cehteh	git fetch -f -u -k --mirror-all git://git.pipapo.org/mala failed with error code 0	18:59
	Log follows:	18:59
	Usage: /home/pasky/bin/git-fetch <fetch-options> <repository> <refspec>...	18:59
pasky	uhhmmm	18:59
	what started going wrong?	18:59
cehteh	note that my server still runs on 1.4 git toolset	19:00
	but that shouldnt be the cause i think	19:00
pasky	ignore that	19:00
cehteh	the other repos are at lest present .. and moment i check my logs ... likely updated later	19:02
	Apr 27 20:58:52 starmaster git-daemon: [10725] Connection from 62.24.64.27:19905	19:03
	your ip?	19:03
	yes	19:04
pasky	I have no idea what caused it... I'm redoing the update rn now, that should fix things, but I probably won't be able to figure out what went wrong	19:06
	cehteh neither .. some strange glitch	19:06
pasky	can you please give me HEAD commit id?	19:06
cehteh	for which project?	19:06
pasky	cinelerra	19:07
	there is another too?	19:07
cehteh	i have serveral projects registered	19:07
pasky	any other broken?	19:07
cehteh	the others are at least still present .. dont look broken but i didnt checked carefully	19:07
	but the glitch is some time ago .. and there where updates running after that which reported no problems	19:08
	galaxy:/var/www/.cinelerra-svn_sync$ cat .git/HEAD	19:09
	ref: refs/heads/origin	19:09
	galaxy:/var/www/.cinelerra-svn_sync$ cat .git/refs/heads/origin	19:09
	efd37bb2dfe5d3c717d5c11b82824af0181a3535	19:09
	thats cinelerra/svn .. the seed repo	19:09
pasky	thanks	19:10
	hmm	19:10
	this looks very bad	19:10
cehteh	there was one workin fork registered cinelerra/pmdumuid	19:10
pasky	git.git lost all refs too	19:10
	as well as linux-2.6.git	19:10
	git.git had refs short while ago...	19:10
cehteh	and one broken (my fault) fork cinelerra/ct	19:10
pasky	there's no fork like that	19:10
cehteh	yeah initial sync failed because of a typo .. but i couldnt figure out how to correct that	19:12
	the web frontend has some usability problems with me :)	19:12
	i could login into some other registered project .. but i couldnt log out and log into cinelerra/ct ... and i even didnt figure out how to logout and supply a diffrent password	19:13
pasky	that's problem of your web browser then :)	19:14
	but yeah, it should've been rewritten without http auth	19:14
cehteh	actually pull repos could be done in some shoot and forget way ... no auth, nothing	19:14
	→ lyakh joined	19:15
	→ hackbert joined	19:15
pasky	well that's pretty much how it is done	19:15
cehteh	just sync them regulary and stop syncing after each try for 2 days or so failing	19:15
pasky	you need auth only if you want to alter the repo after setting it up	19:15
cehteh	ok that way my problem .. typed something wong when registering ..	19:16
	but didnt know how to login	19:16
	lemme try to register my repo again	19:16
pasky	well you don't want for any stranger to come by and repoint urls of existing repos	19:17
cehteh	yeah sure ...	19:18
	but i hate to litter passwords all over the net .. so i tend to use some easy common one over and over again for sites which dont require strong protection	19:19
	http auth isnt in any way secure anyways	19:20
pasky	the point of http auth is that it's trivial to set up	19:21
	:)	19:21
cehteh	Project with that name already exists.	19:21
	.. when i try to register again cinelerra_cv/ct	19:21
	may you just wipe it (account data) then i can register anew	19:22
pasky	?	19:22
	what "account data" do you mean?	19:22
cehteh	dunno .. i dont know your software :P	19:22
pasky	I dunno either	19:22
cehteh	but i cant register it anew	19:22
pasky	mad destruction isn't solution for the problem	19:23
cehteh	somewhere deeply hidden are still some traces from my first attempt to register it	19:23
pasky	well if you tell me where... ;)	19:23
cehteh	it never mirrored .. but the auth data is somewhere stored username/projectname/password	19:23
pasky	it isn't	19:24
cehteh	give me root on that box and i do a 'rgrep cinelerra_cv/ct'	19:24
	well I cant recreate that account and thats clearly a response from your server .. not a fault in my browser	19:24
	where does it store passwords/auth info and which projects to mirror	19:26
	→ dduncan joined	19:26
pasky	just please wait	19:26
cehteh	git clone --reference /srv/git/cinelerra_cv.git/ --bare git://git.pipapo.org/git/cinelerra/ct repodir failed with error code 0	19:27
	Log follows:	19:27
	fatal: unexpected EOF	19:27
	fetch-pack from 'git://git.pipapo.org/git/cinelerra/ct' failed.	19:27
	.. is what i once got (serveral month ago)	19:27
	git://git.pipapo.org/git/cinelerra/ct was wrong, should be ... git://git.pipapo.org/cinelerra/ct	19:27
	(thats the proof, too much git is no good)	19:28
	→ Pistahh joined	19:44
	→ dipplum joined	19:44
pasky	huh, so I don't get this at all :(	19:49
	few moments ago it was there and now /srv/git/cinelerra_cv.git disappeared as well?!	19:49
cehteh	heh	19:52
pasky	aha, I understand how it happenned	19:52
cehteh	some quota?	19:53
pasky	it was actually one of obscure bugs I've fixed, but removing /srv/git/cinelerra_cv.git was an unexpected consequence of the bug :)	19:53
cehteh	or strange setup on my side?	19:53
	heh	19:53
pasky	user gitster not found: /m/p/editproj.cgi	19:53
cehteh	nice that all is mirroed and backed up :P	19:53
pasky	I call "caught!"	19:53
	:))	19:53
gitster	pasky, what's "username and password for RepoAdministration"?	19:54
pasky	I managed to confuse gitster too, yay	19:54
	gitster: username is project name	19:54
	password is project password	19:54
gitster	Hmmm. It does not seem to like me.	19:54
cehteh	projectname for forks is projectname/forkname ?	19:54
	yeah i had some problems with that too	19:54
	pmdumuid reported me too that he couldnt login	19:55
pasky	drop the .git, gitster :)	19:55
	I'll throw away the whole httpauth thing	19:56
	but first I need to figure out why are refs disappearing all over the place	19:56
gitster	Ah, thanks. I rarely do this (and I suspect others).	19:56
	The earlier "insanely long arguments" sounds very suspicious...	19:56
	There is no way to disallow forks?	19:57
pasky	cehteh: so, can you please re-register the cinerella_cv project?	19:57
	er, cinelerra	19:57
	I never remember which way to spell it	19:57
cehteh	_cv ... which one .. main branch or my fork? .. or pmdumuid's fork?	19:58
pasky	gitster: no way; would that be useful for anything?	19:58
	cehteh: main branch	19:58
cehteh	ok	19:58
gitster	I do not like the idea of sharing object store with others.	19:58
pasky	why?	19:58
cehteh	Initiated mirroring. You will be notified by mail about results. ... fine	20:00
gitster	If prune is not implemented properly, I can screw up forked projects, as I rewind 'pu'. I do not want to have forks to alt-git (and that is why I do not ask pushing into git.git).	20:00
cehteh	gitster: i dont do that on my server either ... but that one has mucho HD space and no much users	20:00
gitster	And there is a small matter of SHA-1 collisions, which I do not seriously worry about not yet.	20:00
pasky	gitster: there is no prune	20:00
	and if there is, it will affect git.git just the same as alt-git.git, no?	20:00
cehteh	has anyone ever reported an accidental sha-1 collision? do the math :)	20:01
pasky	I'm probably missing anything...	20:01
gitster	As long as alt-git.git is standalone and "git prune" or "git gc" runs in there, there won't be. I am worried about people (forks) borrowing from git.git.	20:01
pasky	*something	20:01
	gitster: "won't be" what?	20:01
gitster	And if you run "git prune" in git.git, without taking other repositories that borrow from it into account, you can lose objects others still rely on.	20:02
pasky	yes	20:02
	but that's kinda the point	20:02
gitster	s/won't be/& an issue/;	20:02
pasky	I don't run "git prune" in git.git	20:02
	I don't understand your point at all	20:02
	if I ever run git prune, I break all the forks, no matter if they grow from git.git or alt-git.git	20:02
	don't I?	20:02
cehteh	pasky: can you give the cinelerra_cv mirroring a nudge please, then i can re-register the forks	20:02
pasky	I'm not sure if you agree with that or not	20:02
gitster	As I did _not_ know that you do not run "git prune" nor "git repack -a -d", I was worried.	20:02
pasky	I do run git repack -a -d but as far as I understand, that should be fine	20:03
gitster	Huh? "repack -a -d" within git.git?	20:03
	What happens if an object only on 'pu' was already packed (you run prune-packed, don't you?), pu is rewound/rebased, and then you run "repack -a -d" again?	20:04
	And that object was borrowed by one of the forks?	20:04
pasky	gitster: according to git-repack documentation no objects should be removed	20:04
	gitster: only redundant ones	20:05
	maybe the documentation is using some obscure definition of "redundant" I'm not familiar with	20:05
gitster	redundant within that repository. In short, my worry comes from the fact that I do not know what you are doing to ensure that reachability extends to forks.	20:05
pasky	cehteh: not much nudge I can give it, really	20:06
cehteh	ok .. then i wait	20:06
pasky	gitster: I'm relying on git to ensure it for me	20:06
	gitster: if I can't do that, something is seriously badly broken	20:06
	gitster: well "redundant" means duplicate	20:07
cehteh	pasky: i doubt git does that .. or are child repos (how do u call them) referenced from the master .. which would also be bad since the childs then have to have write access into the master	20:07
pasky	gitster: does "unreachable" mean "duplicate"?	20:07
cehteh	duplicate means in more than one pack? .. hence hash-addressed objects cant be duplicate by definition	20:08
pasky	in short, dropping unreachable objects in the process of git-repack -a -d is absolutely ludicruous, especially the way git-repack -a -d is documented now	20:08
cehteh	ok .. mirror is running	20:09
pasky	cehteh: still seems to be fetching yet	20:09
cehteh	yes .. should take some time	20:10
	i meant fetching is running .. nit finished	20:10
	cinelerra is not small, but my upstream is	20:10
pasky	ah.. so it was for 10 minutes already :)	20:10
	but it just finished	20:10
cehteh	yes	20:11
	and pmdumuid's branch is there too	20:11
	→ rphillips joined	20:11
cehteh	now i try to register my branch?	20:11
pasky	yep	20:11
cehteh	Initiated mirroring. You will be notified by mail about results.	20:12
	fine	20:12
	mhm .. and i think a git-svnimport is haning here ... my problem	20:13
	mhm	20:15
	ok .. but now the HEAD the web-frontend displays is 'master' .. would you take add it to the gitweb/repo.or.cz wishlist, that this is configureable?	20:16
	→ wifs joined	20:16
cehteh	http://www.pipapo.org/gitweb?p=cinelerra/ct;a=summary <<head == refs/ct	20:17
wifs	I'm trying to tunnel git via ssh, replacing git://realhost/repo with git://ssh-host/repo	20:17
	what port does git use?	20:17
pasky	cehteh: HEAD should be the same on both sides	20:17
cehteh	its not	20:18
pasky	on a second thought, that's quite possible if you're checking over git://	20:18
	that'll be fixed in future git versions, if I write the patch :)	20:18
cehteh	wifs: when you use host:dir then it uses ssh automatically	20:18
	afaik there is some notation too ssh+git:// ?	20:19
	or is that only cogito?	20:19
wifs	yes, but I don't have ssh access on the repo host	20:19
cehteh	ssh:// ...?	20:19
	ah	20:19
pasky	wifs: 9418	20:20
cehteh	you need write access or just for fetching?	20:20
	firewall problem	20:20
wifs	just fetching	20:20
cehteh	there was some problem to get git over http working on macosx ...	20:21
	dunno if steve fixed that meanwhile	20:21
pasky	gitster: I'd still like to know if git-repack -a -d can remove unreachable objects too, whether it should, if it's a bug/feature and why is it not documented...	20:22
wifs	pasky: thanks!	20:22
pasky	gitster: I've bounced you the insanely long action error	20:30
	→ GyrosGeier joined	20:31
	→ johill joined	20:41
pasky	gitster: looks like the entire mammoth git fetch commandline gets inserted to GIT_REFLOG_ACTION, causing git to puke	20:46
gitster	documentation fixes probably is needed but we have warned about pruning/repacking alternates for a long time.	20:49
	gitster was away for lunch.	20:50
pasky	gitster: where is any warning about repacking vs alternates in the documentation?	20:51
gitster	I suspect you are being dense on purpose -- I meant list archives.	20:51
	I agree that we would need documentation updates to help new people, but I at the same time think you know why unreachable objects will not be included in new pack upon "-a -d" already.	20:53
	→ segher__ joined	20:53
pasky	gitster: in reality I haven't seem almost any git internals in 0.5 year and forgot a lot of stuff	20:53
	but I can guess :)	20:54
	still I realy heavily on documentation	20:54
	← johill left	20:54
	jwb → jwb_gone	20:55
	→ spuk- joined	21:11
	→ devogon joined	21:32
	→ jkroon joined	22:15
jkroon	I have uncommited files and changes, and I need to switch to another branch to do a quick fix, whats the best way to do this ?	22:16
wifs	jkroon: svn diff > patchfile ; svn switch <other branch> ; <do branch changes> svn switch <orig. branch> ; patch -p0 < patchfile ?	22:19
	or you can be ultra lazy and just switch the dirs you need to maybe	22:19
	wifs shrugs	22:19
jkroon	svn? thats blesphamy in here	22:22
robinr	or make a temporary commit	22:22
	jkroon: hope it is a mis-spelling :)	22:22
jkroon	but ok.. I thought maybe git had a special utility	22:23
robinr	you can make a commit, and update it later on	22:23
	i.e. when you switch back	22:23
	just don't publish it or start new branches from it	22:24
jkroon	robinr, which command is that for updating the latest commit ?	22:24
	robinr, right	22:24
robinr	git commit --amend	22:24
jkroon	robfitz, ok thanks	22:26
	robinr, so If I pass --amend and commit, git first removes the most recent commit, throws in my latest changes, and recommits it ?	22:28
robinr	yes	22:29
jkroon	I see	22:29
gitster	if quickfix does not overlap with what you are doing, you can just do "git checkout <the-other-branch>" to switch to it, make a quickfix, and come back with another "git checkout <i-was-on-this-branch>".	22:39
jkroon	the damage is already done :) but thanks for the tip	22:40
	→ avuton joined	22:50
	→ Gitzilla joined	23:15
jkroon	cool, worked like a charm	23:34
	jkroon hugs git-rebase	23:35
	tcoppi → tcoppi_out	23:50
	→ jaalto joined	23:51
jaalto	How do I "cat" that latest revision of file in the current branch?	23:51
numbah	git-show HEAD:file.c	23:52
jaalto	thanks. Is there an easy way to remove "M"odified stag from files whose content hasn't changed?	23:53
numbah	git-checkout file.c	23:53
	you probably have some changes in it if git says so	23:54
jaalto	Oh, you can do that to file as well? (I only have used it to switch between branches)	23:54
	Well, I have some "M" files, but running git-diff does not display anything, so I want to clear those before commit	23:55
numbah	git-status states that they have changed?	23:55
	you have modified it's permissions?	23:56
jaalto	This is under Cygwin and the listing looks like	23:59
	$ git-status	23:59
	# modified: abbrevlist.el	23:59
	...	23:59
	$ git-diff --abbrevlist.el	23:59
	diff --git a/abbrevlist.el b/abbrevlist.el	23:59

Logs Search ←Prev date Next date→

Channels Documentation