On 08/14/2013 07:14 AM, Junio C Hamano wrote:
> Sitaram Chamarty <sitaramc@xxxxxxxxx> 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.
--
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