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

[Thomas Rast <trast@inf.ethz.ch>]

Ramkumar Ramachandra <artagnon@gmail.com> writes:

> 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