Re: [PATCH 2/3] teach sha1_name to look in graveyard reflogs
- From
Jeff King <peff@peff.net>
- Date
- Jul 20, 2012, 15:53 UTC
- Message-ID
- <20120720155341.GD2862@sigill.intra.peff.net>
- In-Reply-To
- <7vtxx3tlyb.fsf@alter.siamese.dyndns.org>
On Thu, Jul 19, 2012 at 03:39:24PM -0700, Junio C Hamano wrote:
Show 12 quoted lines
> > Similarly, for_each_reflog_ent learns to fallback to
> > graveyard refs, which allows the reflog walker to work.
> > However, this is slightly less friendly, as the revision
> > parser expects the matching ref to exist before it realizes
> > that we are interested in the reflog. Therefore you must use
> > "git log -g deleted@{1}" insted of "git log -g deleted" to
> > walk a deleted reflog.
>
> This may or may not be related, but I vaguely recall that "log -g"
> traversal hack had a corner case where the walking stops prematurely
> upon seeing a gap (or creation/deletion that has 0{40})? Do you
> recall if we have ever dealt with that?>From my tests, I think it is probably still broken (if you do a delete,
create, delete sequence on a branch and then walk the reflog, it stops prematurely at the 0{40} sha1).
But what _should_ it show for such an entry? There is no commit to show in the reflog walker, but it would still be nice to say "BTW, there was a deletion even here". Obviously just skipping it and showing the next entry would be better than the current behavior of stopping the traversal, but I feel like there must be some better behavior.
-Peff