[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <47D6D96D.2000302@garzik.org>
Date: Tue, 11 Mar 2008 15:11:41 -0400
From: Jeff Garzik <jeff@...zik.org>
To: Junio C Hamano <gitster@...ox.com>
CC: git@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [ANNOUNCE] GIT 1.5.4.4
Junio C Hamano wrote:
> Jeff Garzik <jeff@...zik.org> 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@...tzel libata-dev]$ git count-objects -v
count: 51
size: 244
in-pack: 475
packs: 4
prune-packable: 0
garbage: 0
[jgarzik@...tzel libata-dev]$ git fsck-objects
[jgarzik@...tzel 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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists