Re: [PATCH 2/6] t1414: document some reflog-walk oddities

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux