Nicolas Pitre [off-list ref] writes:
On Fri, 4 Jan 2008, Michael Stefaniuc wrote:
quoted
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.
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.
Junio C Hamano wrote:
Nicolas Pitre [off-list ref] writes:
quoted
On Fri, 4 Jan 2008, Michael Stefaniuc wrote:
quoted
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