Re: [egit-dev] Fwd: Should I be able to Merge content when Synchronizing

["Thomas Fletcher" <thomas@xxxxxxxxxxxxxxxxx>]

>-----Original Message-----
>From: Christian Halstrick [mailto:christian.halstrick@xxxxxxxxx]
>Sent: Wednesday, April 06, 2011 4:05 PM
>To: Thomas Fletcher
>Cc: Manuel Doninger; EGit developer discussion
>Subject: Re: [egit-dev] Fwd: Should I be able to Merge content when Synchronizing?
>
>> This is _exactly_ my problem.
>>
>> If there are only differences in the incoming version then there is
>> effectively no merge required so a replacement of the current with
>> the incoming is appropriate.
>>
>> If there is any sort of difference between the current and incoming
>> then there may be no textual conflict, but there is a 'model' conflict
>> that I want to resolve through my comparator.
>
>I guess I know what you mean but what you wrote is not so clear. Let
>me summarize what JGit will do during a merge with the default merge
>strategy "resolve":
>
>1. imagine you have checked out commit <a> and you are trying to merge
>with commit <b>
>2. jgit will look at the revision graph and find out the common
>predecessor <base> between <a> and <b>
>3. jgit will now iterate over every file f found in <a> or <b> or
><base> and compares the content of the file in the three states
>4a. content(f, a)=content(f, b) (both commits have the same content)
>-> no conflict, content(f, a) will remain to be content for the file
>4b. content(f, base)=content(f, b) (nothing was changed in b) -> no
>conflict, content(f, a) will remain to be content for the file
>4c. content(f, base)=content(f, a) (nothing was changed in a) -> no
>conflict, content(f, b) will become new content for the file
>4d. else (all three contents differ) -> try a three-way-merge. If that
>merge succeeds -> no conflict,
>      if If that merge does not succeed -> conflict, put the three
>contents into the index (stage 1,2,3) and put the merge result
>      (with conflict markers) into the workingtree file

This is a great explanation of the evaluation process I assumed existed.
It is certainly clearer than what I wrote, and would be a great 
contribution to clarify the behaviour for folks coming from the Eclipse
SVN world.

>There is also a merge strategy "SimpleTwoWayInCore" in which is
>similar to "resolve" but where 4d is different
>4d'. else (all three contents differ) -> always report a conflict, put
>the three contents into the index (stage 1,2,3)
>That sounds much like what you want, right. Problem: The merge
>operation is done with the same algorithm for all files.
>Is that's a problem for you, or are all your files of that kind that
>you want your special merge-driver? Another problem:
>From EGit you currently cannot choose the merge strategy. But we could
>add such an option to the repository configuration
>so you can choose for the merge algorithm which should be used.

For myself, I want that all of my model files (identified by nothing more
than a specific filename extension) are treated such that they kick into
your "SimpleTwoWayInCore" mode and then will mark the file as conflicted
for the user to 'self-resolve' ... presumably using my own comparator.

I haven't experimented, but how does git deal with merging changes to
binary content such as images?  Obviously there would be no sensible 
automated merge strategy in those cases so they must fall into the same
situation as hitting the SimpleTwoWayInCore code path?

If exposing the jgit functionality in the egit UI is of interest, I'd
be happy to do that ... assuming that it makes sense in a broader scope.

Thanks,
 Thomas