LKML Archive on
help / color / mirror / Atom feed
From: Jeff Garzik <>
To: Junio C Hamano <>
Subject: Re: [ANNOUNCE] GIT
Date: Tue, 11 Mar 2008 15:11:41 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Junio C Hamano wrote:
> Jeff Garzik <> 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.


      reply	other threads:[~2008-03-11 19:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-23 21:07 [ANNOUNCE] GIT Junio C Hamano
2008-03-09 10:46 ` [ANNOUNCE] GIT Junio C Hamano
2008-03-09 16:56   ` Jeff Garzik
2008-03-09 20:28     ` Junio C Hamano
2008-03-09 21:42       ` Jeff Garzik
2008-03-10  6:34         ` Junio C Hamano
2008-03-11 19:11           ` Jeff Garzik [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \
    --subject='Re: [ANNOUNCE] GIT' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).