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

From: Thomas Rast <trast@inf.ethz.ch>
Date: Apr 22, 2013, 19:15 UTC
Message-ID: <87zjwqpebl.fsf@hexa.v.cablecom.net>
In-Reply-To: <CALkWK0k0LbAnkhAAqdeAvBnCig_HO+bT+WiQuQQ3Fgc=FzFtRw@mail.gmail.com>

Ramkumar Ramachandra <artagnon@gmail.com> writes:

Show 16 quoted lines

> Ramkumar Ramachandra wrote:
>> And if you're still not convinced, run 'git log HEAD^2 -- README.md'
>> from the toplevel directory.  You'll get the log of README.md from the
>> subproject.
>
> On IRC, Thomas explained to me that mixing in changes from various
> branches into the pathspec will break this so-called determinism.  To
> try it out for yourself, do:
>
>     $ cd /tmp
>     $ git clone gh:trast/subtree-mainline-example
>     $ cd subtree-mainline-example
>     $ git log HEAD^2 -- sub # only lists the side changes
>     $ git log -- dir/sub # only lists the mainline changes
>
> What we should really expect is a mix of the two.

So after lots of confusing misunderstandings across the entire thread, and a long IRC discussion, I do have one take-away that I think is worth writing down:

There is a market for a rename detection that works at the tree level.

Bear with me while I explain.

The average subtree merge (after the initial one) looks like this, focusing on the subtree:

  M    new state in sub/
  | \
  |  * new state in /
  |
  * old state in sub/

(The example in the quote above additionally complicates the issue by changing sub/ in the mainline.)

Ideally we'd like our hypothetical fixed --follow to accurately track a pathspec 'sub/foo' so that in the mainline it remains the same, but in the side it becomes 'foo'. Because of reasons already explained in earlier mails, -M does not suffice for all cases (in particular, it fails if there is a /foo in the mainline too). -C works, but is slow.

So how can we fix that? We could try to somehow figure out that M:sub/ refers to the same thing as M^2:/, by looking at them at the tree level. Let's provisionally call this --follow-tree-rename.

I don't quite know how to heuristically[1] detect such a rename, but since 'merge -ssubtree' does it (if you don't specify a tree prefix explicitly), it can't be That Hard(tm). If we're extra lucky it's fast enough to be enabled by default.

In the special case where the subtree was not modified in the mainline since the last merge, the problem is pretty trivial: simply check if any subtree of M agrees with the root tree of each merge parent; if so, diff those trees instead of the root trees.

That should then help subtree users to get better logs.

[1] the quoted example shows that you can't just go looking for identical trees in the general case, so it is really a heuristic

-- 
Thomas Rast
trast@{inf,student}.ethz.ch