On 05/07/17 09:00, Jeff King wrote:
> Since its inception, the general strategy of the reflog-walk
> code has been to start with the tip commit for the ref, and
> as we traverse replace each commit's parent pointers with
> fake parents pointing to the previous reflog entry.
>
> This lets us traverse the reflog as if it were a real
> history, but it has some user-visible oddities. Namely:
>
> 1. The fake parents are used for commit selection and
> display. So for example, "--merges" or "--no-merges"
> are useful, because the history appears as a linear
> string. Likewise, pathspec limiting is based on the
> diff between adjacent entries, not the changes actually
> introduced by a commit.
>
> These are often the same (e.g., because the entry was
> just running "git commit" and the adjacent entry _is_
> the true parent), but it may not be in several common
> cases. For instance, using "git reset" to jump around
> history, or "git checkout" to move HEAD.
>
> 2. We reverse-map each commit back to its reflog. So when
> it comes time to show commit X, we say "a-ha, we added
> X because it was at the tip of the 'foo' reflog, so
> let's show the foo reflog". But this leads to nonsense
> results when you ask to traverse multiple reflogs: if
> two reflogs have the same tip commit, we only map back
> to one of them.
>
> Instead, we should show each reflog individually, in
> the order the user gave us on the command line.
>
> 2. If the tip of the reflog and the ref tip disagree on
^^
It seems hard to get off the second point! ;-)
ATB,
Ramsay Jones
