Re: ephemeral-branches instead of detached-head?

From: Sitaram Chamarty <sitaramc@gmail.com>
Date: Aug 14, 2013, 06:32 UTC
Message-ID: <520B2478.3000100@gmail.com>
In-Reply-To: <7vmwolujvb.fsf@alter.siamese.dyndns.org>

On 08/14/2013 07:14 AM, Junio C Hamano wrote:

Show 15 quoted lines

> Sitaram Chamarty <sitaramc@gmail.com> writes:
> 
>>     # all reflog entries that are not on a branch, tag, or remote
>>     d1 = !gitk --date-order $(git log -g --pretty=%H) --not --branches --tags --remotes
>>     # all dangling commits not on a branch, tag, or remote
>>     d2 = !gitk --date-order $(git fsck | grep "dangling.commit" | cut -f3 -d' ') --not --branches --tags --remotes
>>
>> (Apologies if something like this was already said; I was not following
>> the discussion closely enough to notice)
> 
> Yup.
> 
> A potential problem is that the output from "log -g --pretty=%H" or
> "fsck | grep dangling" may turn out to be humongous.  Other than
> that, they correctly compute what you want.

I thought I mentioned that but I can't find my email now so maybe I didn't.

In practice though, I find that, bash at least seems happy to take command lines as long as 7+ million characters long, so with the default reflog expire times, that should work out to 10,000 commits *per day*. [Tested with: echo {1000000..1900000} > junk; echo `cat junk` | wc]

Incidentally, am I the only one who thinks the default values for gc.reflogexpire (90 days) and gc.reflogexpireunreachable (30) should be reversed?

In terms of recovering potentially lost commits at least, it seems it would make more sense that something that is UNreachable have a longer expiry, whereas stuff that's reachable... that's only a quick "gitk" browse away.

Design question: is the primary purpose of the reflog "what was I doing X days ago" or is it "I need some code from a commit that got rebased out [or whatever] X days ago"?

I have always only used the reflog for the latter.