Junio C Hamano wrote:
Jeff Garzik <jeff@xxxxxxxxxx> writes:
Yes, I regularly run both 'git gc' and 'git prune'.
But since (ref original email) I was doing some rebasing, there are
inevitably changesets left dangling after such an operation.
Yeah, I'd say it is stupid if "am" ran "gc --auto" for every patch. I
recall that we had the same issue with git-svn and we made it run once
every 1k round, and we probably should do the same for "am" and "rebase",
running once at the very end.
Perhaps we would want to raise the default "gc --auto" limit? Currently
That seems quite reasonable. This "feels" like a threshold-too-low problem.
when it estimates that you have roughly 6700 objects unpacked it runs
"repack --prune-packed", and if there still are that many unpacked objects
after that, it suggests you to run "git prune" to remove them. If you are
rebasing, the commits in the old history that are rewritten will _not_
immediately become dangling because they will still be reachable from your
reflog. If you are getting the message, these objects were already
dangling (ancient commits that are not even reachable from your reflog
entries that are by default kept for 90 days) even before you started your
rebase or am run.
My workflow generally looks like this:
# repo was created in this manner.... this was done ONCE,
# not every time I apply patches
git clone --reference ../linux-2.6 ../linux-2.6 libata-dev
# a patch-applying session
git checkout master
git pull ../linux-2.6
git fetch --tags ../linux-2.6 # yes, still necessary...
git branch -D ALL NEXT
git branch -D upstream-fixes upstream-linus
git checkout -b upstream-fixes master
git-am --utf8 --signoff -i /g/tmp/mbox # repeat many times...
git branch upstream-linus upstream-fixes
git-checkout sii-lbt && git-rebase master
git-checkout mv-ahci-pata && git-rebase master
git-checkout new-eh && git-rebase master
git branch NEXT master
git branch ALL new-eh
git checkout master
git prune
git push --force --all $URL
Thus, 'git prune' is run on a very regular basis, but 'git gc' is not.
However, I presume the lack of 'git gc' regularity on libata-dev.git is
mitigated by the fact that I _do_ run 'git gc' regularly on
linux-2.6.git (listed in libata-dev's alternatives, as noted by
git-clone statement above)
After you finished your day's work on a typical day, what does the output
from "git count-objects -v" and "git fsck-objects" look like, I wonder?
[jgarzik@pretzel libata-dev]$ git count-objects -v
count: 51
size: 244
in-pack: 475
packs: 4
prune-packable: 0
garbage: 0
[jgarzik@pretzel libata-dev]$ git fsck-objects
[jgarzik@pretzel libata-dev]$
As an aside... a git-debug-info might be a useful command, wrapping up
everything you (a git developer) would find interesting from me (a
humble and appreciative git user). Users could attach the output from
git-debug-info to emails, when discussing problems in their repositories.
Jeff
--
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
