Re: [PATCH] git-am: Run git gc only once and not for every patch.

[Michael Stefaniuc <mstefani@redhat.com>]

Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
> 
>> On Fri, 4 Jan 2008, Michael Stefaniuc wrote:
>>
>>> With "too many unreachable loose objects" git gc --auto will always
>>> trigger. This clutters the output of git am and thus git rebase.
>>>
>>> The work flow of the Wine project doesn't include git merge. git rebase
>>> is therefor used to track the origin. This will produce soon too many
>>> loose objects for git gc --auto's taste. Pruning the repository would
>>> "fix" it. But we tell Wine developers new to git to NOT prune as long as
>>> they aren't confident enough with git; just as a safety net in case they
>>> have thrown away month of work.
>> The safety is the reflog.  What it refers to doesn't get pruned.
> 
> What Nico said.
Not sure if you read my reply to Nico but the reflog is not there for
deleted branches. Nor for a cleared stash. Common operations where one
can loose work by mistake.

> More importantly, ones who are not confident with git would not
> be able to resurrect unreachables that are left unpruned anyway.
> The unreachables are by definition not connected to anything, so
> they cannot do much better than grepping through droppings left
> by "fsck --lost-found", which they probably even do not know how
> to do yet.
The smarter ones come and ask on irc. We helped a few people with git
problems on the Wine channels. Depending on the amount of time someone
put into his "lost" work grepping through "fsck --lost-found" might be
well worth it.

Nevertheless is there a reason why git gc needs to run after applying
each patch in git-am? Why can't it run just once at the end? git prune
is optional and there's no reason to penalize a user that doesn't feel
safe to run it by cluttering the output of git am/rebase. There is also
a time penalty: git gc --auto on a pruned tree runs so fast that it
isn't measurable but on my unpruned wine it took 1.5 seconds. Waiting
1.5 seconds per am/rebase is acceptable; wasting 1.5 seconds per patch
in the mailbox/rebase isn't that much fun if there are more than a
handful of patches to apply.

bye
	michael
-- 
Michael Stefaniuc                           Tel.: +49-711-96437-199
Consulting Communications Engineer          Fax.: +49-711-96437-111
--------------------------------------------------------------------
Reg. Adresse: Red Hat GmbH, Hauptstätter Strasse 58, 70178 Stuttgart
Handelsregister: Amtsgericht Stuttgart HRB 153243
Geschäftsführer: Brendan Lane, Charlie Peters, Michael Cunningham,
                 Werner Knoblich