Michael Stefaniuc <mstefani@xxxxxxxxxx> writes: >> 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. I am sure you read what Nico pointed out about HEAD reflog. > 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. "Optional" does not mean "whether you do it or not you will see identical behaviour". Not pruning may slow things down but you may still choose not to prune and suffer the penalty --- that's your choice. But we still produce the correct result (hopefully ;-) --- and that is what "Optional" means. The message from "gc --auto" may serve as a coalmine canary for you to know when to prune. I do not think moving "gc --auto" outside the loop hurts in practice because you are not likely to be rebasing a truly huge series every day, but cruft can accumulate during "git am" run and the "gc --auto" inside loop was meant to clean them up. The idea was taken from importers that run repack every once in a while (e.g. cvsimport runs every 1k commits), but "gc --auto" was designed to be much more lightweight than a full repack and that was the reason it was placed in the loop without counting "every N commits". - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
