[MERGE] LCA Merge resolution for tree-shape

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


...

> 
>>> This is mind-melting.  Can we please simplify _entries_lca so that it
>>> emits *everything* except entries that are the same in THIS and OTHER?
>>> Trying to keep track of when it defers merge resolution to merge_names
>>> vs resolving the merge itself is not easy.
>> Well, because it does it correctly, and keeps us from having to deal
>> with entries that are not genuinely modified. I realize it is complex.
>> Most of that is real-world complexity derived from examples in the mysql
>> history. I believe this is one of the explicit points that they ran
>> into. Their merge case does indeed have a double-criss-cross that causes
>> things to look modified when they shouldn't. To get the merge correct,
>> we have to treat those paths and content as unmodified. (Because it
>> genuinely hasn't given the per-file graph.)
> 
> Certainly I'm not trying to say we shouldn't address such cases.  I'm
> trying to say we shouldn't address such cases in _entries_lca.
> 
>> In order to generate the right values for the various fields (content
>> changed, filename changed, etc) I've done 90% of the work of figure out
>> whether or not we need to do any more work. Why not just omit the ones
>> that I know don't need to be processed further?
> 
> This change puts a big dent in our separation of concerns.  I don't have
> a big investment in any particular separation of concerns, I just want
> it to be clear what they are.

...

>> 4) Changing _entries_lca to return everything where THIS != OTHER. The
>> point of what I wrote is to only return entries where OTHER != "base"
>> (where base is also made up of lcas as appropriate.)
> 
> 1, 2, and 4 are the only substantial concerns I had, so not addressing
> them gets you another

So I think a thread just discussing this is important to have.

Your specific request is to return everything when "THIS != OTHER". I
would actually argue that the correct api is to return when OTHER !=
BASE. We don't really care what has happened in THIS when merging
*except* when it happens to conflict with what happened in OTHER.

For example, merging C into D:

  A	# create foo and bar
  |\
  B C	# B modifies foo, C modifies bar
  :
  D	# D deletes foo

At this point, the delta A => C is only modifying 'bar'. I don't see why
we should care about what happened to 'foo'. If we return everything
where "THIS" != "OTHER" then we just have to check whether anything
really happened again, and filter out the cases where OTHER == BASE.

Now, perhaps you did mean "return everything where OTHER != BASE". In
which case, I'm doing that, with the added complexity that OTHER may
actually == LCA, rather than BASE. (And often, OTHER == PER_FILE_BASE.)
And in my opinion, the same thought holds. OTHER didn't actually change
anything, so we don't need to evaluate that file further.

I can certainly try to make that clearer in the code. I would also like
to make sure I understand why you think we should return everything for
OTHER != THIS.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkjGp8kACgkQJdeBCYSNAAMDAgCeL6YvhpY0JTOx8PgmGCIx/gBl
mYMAn0g5hu3xOn1JqRJpj+tL9+0rneVF
=6bHZ
-----END PGP SIGNATURE-----