{"thread":{"id":"11475","subject":"[PATCH] git-am: Run git gc only once and not for every patch.","startedAt":"2008-01-04T18:59:26Z","lastAt":"2008-01-05T16:23:49Z","messageCount":9,"participants":["Michael Stefaniuc","Nicolas Pitre","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"64455","messageId":"20080104185926.GA11912@redhat.com","threadId":"11475","inReplyTo":null,"subject":"[PATCH] git-am: Run git gc only once and not for every patch.","fromName":"Michael Stefaniuc","fromEmail":"mstefani@redhat.com","sentAt":"2008-01-04T18:59:26Z","receivedAt":"2008-01-04T18:59:26Z","isPatch":true,"sender":{"key":"mstefani@redhat.com","avatar":null},"body":"With \"too many unreachable loose objects\" git gc --auto will always\ntrigger. This clutters the output of git am and thus git rebase.\n\nThe work flow of the Wine project doesn't include git merge. git rebase\nis therefor used to track the origin. This will produce soon too many\nloose objects for git gc --auto's taste. Pruning the repository would\n\"fix\" it. But we tell Wine developers new to git to NOT prune as long as\nthey aren't confident enough with git; just as a safety net in case they\nhave thrown away month of work.\n\nSigned-off-by: Michael Stefaniuc <mstefani@redhat.com>\n---\n git-am.sh |    4 ++--\n 1 files changed, 2 insertions(+), 2 deletions(-)\n\ndiff --git a/git-am.sh b/git-am.sh\nindex 65c634f..5f0f241 100755\n--- a/git-am.sh\n+++ b/git-am.sh\n@@ -469,9 +469,9 @@ do\n \t\t\"$GIT_DIR\"/hooks/post-applypatch\n \tfi\n \n-\tgit gc --auto\n-\n \tgo_next\n done\n \n+git gc --auto\n+\n rm -fr \"$dotest\"\n-- \n1.5.4.rc2\n"},{"id":"64458","messageId":"alpine.LFD.1.00.0801041437190.2649@xanadu.home","threadId":"11475","inReplyTo":"20080104185926.GA11912@redhat.com","subject":"Re: [PATCH] git-am: Run git gc only once and not for every patch.","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-01-04T19:38:42Z","receivedAt":"2008-01-04T19:38:42Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 4 Jan 2008, Michael Stefaniuc wrote:\n\n> With \"too many unreachable loose objects\" git gc --auto will always\n> trigger. This clutters the output of git am and thus git rebase.\n> \n> The work flow of the Wine project doesn't include git merge. git rebase\n> is therefor used to track the origin. This will produce soon too many\n> loose objects for git gc --auto's taste. Pruning the repository would\n> \"fix\" it. But we tell Wine developers new to git to NOT prune as long as\n> they aren't confident enough with git; just as a safety net in case they\n> have thrown away month of work.\n\nThe safety is the reflog.  What it refers to doesn't get pruned.\n\n\nNicolas\n"},{"id":"64460","messageId":"477E9536.6050401@redhat.com","threadId":"11475","inReplyTo":"alpine.LFD.1.00.0801041437190.2649@xanadu.home","subject":"Re: [PATCH] git-am: Run git gc only once and not for every patch.","fromName":"Michael Stefaniuc","fromEmail":"mstefani@redhat.com","sentAt":"2008-01-04T20:21:10Z","receivedAt":"2008-01-04T20:21:10Z","isPatch":true,"sender":{"key":"mstefani@redhat.com","avatar":null},"body":"Nicolas Pitre wrote:\n> On Fri, 4 Jan 2008, Michael Stefaniuc wrote:\n> \n>> With \"too many unreachable loose objects\" git gc --auto will always\n>> trigger. This clutters the output of git am and thus git rebase.\n>>\n>> The work flow of the Wine project doesn't include git merge. git rebase\n>> is therefor used to track the origin. This will produce soon too many\n>> loose objects for git gc --auto's taste. Pruning the repository would\n>> \"fix\" it. But we tell Wine developers new to git to NOT prune as long as\n>> they aren't confident enough with git; just as a safety net in case they\n>> have thrown away month of work.\n> \n> The safety is the reflog.  What it refers to doesn't get pruned.\nThen git gc --auto should just prune too and not spam, right?\nBut the reflog is only there for branches that still exist; the rest is\ngone. A git stash clear will also remove the reflog for the stash.\n\nRegardless of the safety of git prune i don't see a reason why git gc\n--auto needs to be called for every patch in a git-am run and not once\nat the end.\n\nbye\n\tmichael\n"},{"id":"64462","messageId":"7vhchtjphk.fsf@gitster.siamese.dyndns.org","threadId":"11475","inReplyTo":"alpine.LFD.1.00.0801041437190.2649@xanadu.home","subject":"Re: [PATCH] git-am: Run git gc only once and not for every patch.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-04T20:38:15Z","receivedAt":"2008-01-04T20:38:15Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre <nico@cam.org> writes:\n\n> On Fri, 4 Jan 2008, Michael Stefaniuc wrote:\n>\n>> With \"too many unreachable loose objects\" git gc --auto will always\n>> trigger. This clutters the output of git am and thus git rebase.\n>> \n>> The work flow of the Wine project doesn't include git merge. git rebase\n>> is therefor used to track the origin. This will produce soon too many\n>> loose objects for git gc --auto's taste. Pruning the repository would\n>> \"fix\" it. But we tell Wine developers new to git to NOT prune as long as\n>> they aren't confident enough with git; just as a safety net in case they\n>> have thrown away month of work.\n>\n> The safety is the reflog.  What it refers to doesn't get pruned.\n\nWhat Nico said.\n\nMore importantly, ones who are not confident with git would not\nbe able to resurrect unreachables that are left unpruned anyway.\nThe unreachables are by definition not connected to anything, so\nthey cannot do much better than grepping through droppings left\nby \"fsck --lost-found\", which they probably even do not know how\nto do yet.\n"},{"id":"64465","messageId":"alpine.LFD.1.00.0801041555220.2649@xanadu.home","threadId":"11475","inReplyTo":"477E9536.6050401@redhat.com","subject":"Re: [PATCH] git-am: Run git gc only once and not for every patch.","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-01-04T20:58:43Z","receivedAt":"2008-01-04T20:58:43Z","isPatch":true,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 4 Jan 2008, Michael Stefaniuc wrote:\n\n> Nicolas Pitre wrote:\n> > On Fri, 4 Jan 2008, Michael Stefaniuc wrote:\n> > \n> >> With \"too many unreachable loose objects\" git gc --auto will always\n> >> trigger. This clutters the output of git am and thus git rebase.\n> >>\n> >> The work flow of the Wine project doesn't include git merge. git rebase\n> >> is therefor used to track the origin. This will produce soon too many\n> >> loose objects for git gc --auto's taste. Pruning the repository would\n> >> \"fix\" it. But we tell Wine developers new to git to NOT prune as long as\n> >> they aren't confident enough with git; just as a safety net in case they\n> >> have thrown away month of work.\n> > \n> > The safety is the reflog.  What it refers to doesn't get pruned.\n> Then git gc --auto should just prune too and not spam, right?\n\nPruning might be dangerous if some other operation is happening \nconcurrently, which is why it is not done by default.\n\n> But the reflog is only there for branches that still exist; the rest is\n> gone. A git stash clear will also remove the reflog for the stash.\n\nBut the reflog for HEAD remains nevertheless, and it contains everything \nthat happened to be the current branch.\n\n> Regardless of the safety of git prune i don't see a reason why git gc\n> --auto needs to be called for every patch in a git-am run and not once\n> at the end.\n\nIndeed.\n\n\nNicolas\n"},{"id":"64468","messageId":"477EA06A.5090606@redhat.com","threadId":"11475","inReplyTo":"7vhchtjphk.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-am: Run git gc only once and not for every patch.","fromName":"Michael Stefaniuc","fromEmail":"mstefani@redhat.com","sentAt":"2008-01-04T21:08:58Z","receivedAt":"2008-01-04T21:08:58Z","isPatch":true,"sender":{"key":"mstefani@redhat.com","avatar":null},"body":"Junio C Hamano wrote:\n> Nicolas Pitre <nico@cam.org> writes:\n> \n>> On Fri, 4 Jan 2008, Michael Stefaniuc wrote:\n>>\n>>> With \"too many unreachable loose objects\" git gc --auto will always\n>>> trigger. This clutters the output of git am and thus git rebase.\n>>>\n>>> The work flow of the Wine project doesn't include git merge. git rebase\n>>> is therefor used to track the origin. This will produce soon too many\n>>> loose objects for git gc --auto's taste. Pruning the repository would\n>>> \"fix\" it. But we tell Wine developers new to git to NOT prune as long as\n>>> they aren't confident enough with git; just as a safety net in case they\n>>> have thrown away month of work.\n>> The safety is the reflog.  What it refers to doesn't get pruned.\n> \n> What Nico said.\nNot sure if you read my reply to Nico but the reflog is not there for\ndeleted branches. Nor for a cleared stash. Common operations where one\ncan loose work by mistake.\n\n> More importantly, ones who are not confident with git would not\n> be able to resurrect unreachables that are left unpruned anyway.\n> The unreachables are by definition not connected to anything, so\n> they cannot do much better than grepping through droppings left\n> by \"fsck --lost-found\", which they probably even do not know how\n> to do yet.\nThe smarter ones come and ask on irc. We helped a few people with git\nproblems on the Wine channels. Depending on the amount of time someone\nput into his \"lost\" work grepping through \"fsck --lost-found\" might be\nwell worth it.\n\nNevertheless is there a reason why git gc needs to run after applying\neach patch in git-am? Why can't it run just once at the end? git prune\nis optional and there's no reason to penalize a user that doesn't feel\nsafe to run it by cluttering the output of git am/rebase. There is also\na time penalty: git gc --auto on a pruned tree runs so fast that it\nisn't measurable but on my unpruned wine it took 1.5 seconds. Waiting\n1.5 seconds per am/rebase is acceptable; wasting 1.5 seconds per patch\nin the mailbox/rebase isn't that much fun if there are more than a\nhandful of patches to apply.\n\nbye\n\tmichael\n-- \nMichael Stefaniuc                           Tel.: +49-711-96437-199\nConsulting Communications Engineer          Fax.: +49-711-96437-111\n--------------------------------------------------------------------\nReg. Adresse: Red Hat GmbH, Hauptstätter Strasse 58, 70178 Stuttgart\nHandelsregister: Amtsgericht Stuttgart HRB 153243\nGeschäftsführer: Brendan Lane, Charlie Peters, Michael Cunningham,\n                 Werner Knoblich\n"},{"id":"64470","messageId":"7vmyrli73h.fsf@gitster.siamese.dyndns.org","threadId":"11475","inReplyTo":"477EA06A.5090606@redhat.com","subject":"Re: [PATCH] git-am: Run git gc only once and not for every patch.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-04T22:00:50Z","receivedAt":"2008-01-04T22:00:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael Stefaniuc <mstefani@redhat.com> writes:\n\n>> What Nico said.\n> Not sure if you read my reply to Nico but the reflog is not there for\n> deleted branches. Nor for a cleared stash. Common operations where one\n> can loose work by mistake.\n\nI am sure you read what Nico pointed out about HEAD reflog.\n\n> Nevertheless is there a reason why git gc needs to run after applying\n> each patch in git-am? Why can't it run just once at the end? git prune\n> is optional and there's no reason to penalize a user that doesn't feel\n> safe to run it by cluttering the output of git am/rebase. There is also\n> a time penalty: git gc --auto on a pruned tree runs so fast that it\n> isn't measurable but on my unpruned wine it took 1.5 seconds. Waiting\n> 1.5 seconds per am/rebase is acceptable; wasting 1.5 seconds per patch\n> in the mailbox/rebase isn't that much fun if there are more than a\n> handful of patches to apply.\n\n\"Optional\" does not mean \"whether you do it or not you will see\nidentical behaviour\".  Not pruning may slow things down but you\nmay still choose not to prune and suffer the penalty --- that's\nyour choice.  But we still produce the correct result (hopefully\n;-) --- and that is what \"Optional\" means.\n\nThe message from \"gc --auto\" may serve as a coalmine canary for\nyou to know when to prune.\n\nI do not think moving \"gc --auto\" outside the loop hurts in\npractice because you are not likely to be rebasing a truly huge\nseries every day, but cruft can accumulate during \"git am\" run\nand the \"gc --auto\" inside loop was meant to clean them up.  The\nidea was taken from importers that run repack every once in a\nwhile (e.g. cvsimport runs every 1k commits), but \"gc --auto\"\nwas designed to be much more lightweight than a full repack and\nthat was the reason it was placed in the loop without counting\n\"every N commits\".\n"},{"id":"64506","messageId":"7vve68ep78.fsf@gitster.siamese.dyndns.org","threadId":"11475","inReplyTo":"7vmyrli73h.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-am: Run git gc only once and not for every patch.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-05T06:55:39Z","receivedAt":"2008-01-05T06:55:39Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> ...\n> I do not think moving \"gc --auto\" outside the loop hurts in\n> practice because you are not likely to be rebasing a truly huge\n> series every day, but cruft can accumulate during \"git am\" run\n> and the \"gc --auto\" inside loop was meant to clean them up.  The\n> idea was taken from importers that run repack every once in a\n> while (e.g. cvsimport runs every 1k commits), but \"gc --auto\"\n> was designed to be much more lightweight than a full repack and\n> that was the reason it was placed in the loop without counting\n> \"every N commits\".\n\nHaving said all that, I'll take your patch as-is except that I'd\ndrop the later part of the commit log message that explains\nWine's practice.\n"},{"id":"64537","messageId":"477FAF15.6020202@redhat.com","threadId":"11475","inReplyTo":"7vve68ep78.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git-am: Run git gc only once and not for every patch.","fromName":"Michael Stefaniuc","fromEmail":"mstefani@redhat.com","sentAt":"2008-01-05T16:23:49Z","receivedAt":"2008-01-05T16:23:49Z","isPatch":true,"sender":{"key":"mstefani@redhat.com","avatar":null},"body":"Junio C Hamano wrote:\n> Junio C Hamano <gitster@pobox.com> writes:\n> \n>> ...\n>> I do not think moving \"gc --auto\" outside the loop hurts in\n>> practice because you are not likely to be rebasing a truly huge\n>> series every day, but cruft can accumulate during \"git am\" run\n>> and the \"gc --auto\" inside loop was meant to clean them up.  The\n>> idea was taken from importers that run repack every once in a\n>> while (e.g. cvsimport runs every 1k commits), but \"gc --auto\"\n>> was designed to be much more lightweight than a full repack and\n>> that was the reason it was placed in the loop without counting\n>> \"every N commits\".\n> \n> Having said all that, I'll take your patch as-is except that I'd\nThanks.\n\n> drop the later part of the commit log message that explains\n> Wine's practice.\nYeah, sorry about that. That should have been outside of the commit\nmessage anyway. But forgot about it as the Wine maintainer takes only\nthe subject as commit message.\n\nbye\n\tmichael\n"}]}