Why aren't tree hashes in multiple commits considered for common ancestor?

[svelez]

I've noticed that if I push my subrepo to a branch, and then merge that branch in to master (using a pull request), with no changes necessary to the tree, then my next pull of the subrepo does not recognize the pushed commit as a common ancestor (and I have to re-resolve some earlier merge conflicts).

I think that this is because in subrepo:merge-base, this happens:

        if [[ ${#target_value} > 40 ]]; then
          if $list_all; then
            say "Multiple on $2: $target_value"
          fi
        else

And the multi-match tree is not considered for new_parent and old_parent.

Am I reading this correctly? If so, why is this?
Should I focus on just pushing to a single branch in the subrepo?

Thanks.

[grimmySwe]

The solution in 0.3.0 was an experiment with a new tree hash based implementation. It has been found to have several draw backs so we are working on replacing this with a much more robust variant.

Test out branch "issue/216" and see if that solves your problem.

[svelez]

Yes, that does work better. Thanks 👍. It seems you have been giving that answer a lot lately.
Forgive me for not looking in to the code right now, but what is the fundamental difference with this version now that the tree hash compare is not used? Are the values in .gitsubrepo now driving this?

[grimmySwe]

@svelez Yes we are back to the original idea with having values stored in .gitrepo file. I had some illusion that tree hashes would work and it did but only in very limited scenarios.

[grimmySwe]

0.4.0 reached master.