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

From: Junio C Hamano <gitster@pobox.com>
To: Thomas Rast <trast@inf.ethz.ch>
Cc: Ramkumar Ramachandra <artagnon@gmail.com>,
	Git List <git@vger.kernel.org>,
	Avery Pennarun <apenwarr@gmail.com>
Subject: Re: [PATCH] t4202 (log): add failing test for log with subtree
Date: Mon, 22 Apr 2013 09:32:58 -0700	[thread overview]
Message-ID: <7vk3nupltx.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <87wqruk2pj.fsf@linux-k42r.v.cablecom.net> (Thomas Rast's message of "Mon, 22 Apr 2013 17:24:56 +0200")

Thomas Rast <trast@inf.ethz.ch> 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.