Re: [BUG?] 'git subtree split' replicates unrelated mainline merges into subtree?

["Strain, Roger L." <roger.strain@swri.org>]

(Apologies for message formatting, fighting Outlook)

> I've been trying to understand how the subtree cache (mis)behaves in
> this case. The cache is initially seeded from find_existing_splits(),
> which finds these lines the adc8ecf commit message:
> 
>     git-subtree-mainline: 9b6e8f677b700a00e9f1715e2624bf5ed756dc85
>     git-subtree-split: 5280958b2f997c3ce7bff7192cceb19f55b45cd9
> 
> and adds these corresponding entries to the cache:
> 
>     9b6e8f6 -> 5280958
>     5280958 -> 5280958
> 
> In other words, the cache starts out claiming that 5280958 is the
> equivalent subtree commit for the 9b6e8f6 mainline commit.
> However, in my naive understanding this does not make sense, as
> 9b6e8f6 _precedes_ the subtree addition, and has no content in
> the relevant subdir.


I think you've identified the exact problem right here. In the normal
split/rejoin commits, the mainline commit *prior to* the merge commit
does, in fact, represent the same subtree state as the subtree commit
which is also merged at that point. But in the case of an add, that's
not true, and I'm actually a little surprised the same commit message
markers are generated.

What really should be captured by the initial cache seeding is that
the add merge commit *itself* has the same subtree content. However,
that can't be determined at the time the merge commit is created, as
the hash of that merge commit is determined by the commit message
itself.

I think a possible solution to this would be modifying the initial cache
process to isolate the Add commits and handle them differently.
Rather than using the hashes in the commit message, it should map
the merge commit itself to the subtree-split commit, and either do
nothing with the subtree-mainline commit hash, or explicitly set it
to notree.

However, this will complicate the logic of building the initial cache,
as it currently only cares about the existence of those simple lines,
and adds the mappings, erroneously as you have noted in this case.

It might also be worth changing the commit message provided for
adds so it no longer generates the incorrect assertion that the mainline
commit is identical subtree-wise, but even with that change, support
for correctly handling existing commits would still be ideal.

Currently, we're using a local version of the subtree script based on
some changes laid out here: https://github.com/gitgitgadget/git/pull/493
I'm hopeful that changeset will eventually land here, as it helps with
several complex issues in our repositories. I bring that up also because
it introduces some additional tools for managin the initial cache,
allowing manual mapping of one commit to another. That version might
allow some level of testing on whether this idea would correct the
problem described.

-- 
Roger Strain