Re: [PATCH] t4202 (log): add failing test for log with subtree

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

 



Thomas Rast <trast@xxxxxxxxxxx> writes:

> So (I think?) in the above you claim that $USER interprets
>
>   git log -- README.md
>
> as
>
>   Show me the history of README.md.
>
> But there's no such thing as the history of a file!  The command instead
> says
>
>   If I filter all history for only changes affecting a path 'README.md'
>   in the root of the repository[1], then what does it look like?

Correct.  The "design principle" I did not quote from your message
comes from one of the most important messages in the list archive
($gmane/217).

Three issues with "--follow" are:

 (1) It uses the given pathname as single pathspec and drill down
     the same way without "--follow" until it notices the path
     disappears and until then there is no attempt to detect renames
     is made.  And it only does -M variant of rename detection

 (2) The "same way" in (1) includes the merge simplification to cull
     side branches if one parent matches the end result.  In a
     history where the first parent of a merge M, i.e. M^1, did not
     have path F, its second parent M^2 had path F, and the merge
     result M deposited the contents of M^2:F at M:D/F, then running
     "log --follow F" starting from M would notice that the end
     result M did not have F in it, which is shared with its first
     parent M^1, and culls the side branch M^2.  The --full-history
     option may let you keep the history leading to M^2, though.

 (3) When (1) notices that the path being followed did not exist in
     any of the parents (be it a merge or a non-merge) and finds a
     different path with a similar looking content, it _switches_
     the pathspec to it, but the single pathspec it uses is a global
     state and affects traversals of other ancestry paths at the
     same time.  Because of this, "--follow" will not work correctly
     in a history that contains merges.  It often _appears_ to work
     only by accident.

The first two are relatively minor (the second is not even an
issue).

To solve the last one, you would need to keep track of which path it
is following per traversal path.
--
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




[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]