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

["Thomas Fletcher" <thomas@xxxxxxxxxxxxxxxxx>]

>-----Original Message-----
>From: Dariusz Luksza [mailto:dariusz.luksza@xxxxxxxxx]
>Sent: Tuesday, April 05, 2011 1:05 PM
>To: Thomas Fletcher
>Cc: egit-dev@xxxxxxxxxxx
>Subject: Re: [egit-dev] Should I be able to Merge content when Synchronizing?
>
>On 04/05/11 16:58, Thomas Fletcher wrote:
>> Unfortunately, it seems that the input elements (FileRevisionTypeElement) don't
>> expose the local resource path so that I can actually perform a merge using my compare
>> editor and save the resulting changes, mark the change set as merged and move on.
>
>Currently we don't allow to merge changes in synchronize view, because in Git this is
>much more complicated then in CVS/SVN. In Git we store changes on repository level not
>on file level like CVS/SVN, additionally you can't modify files between two commits;
>you can only merge all incoming changes or rebase yours on top of them. The next issue
>in Git is that after merge you need to add a merge-commit ... this is a common workflow
>that is forced by native git.

Thanks for the detailed answer. I'm still familiarizing myself with the git internals, so 
I expected an answer along the lines of "don't do that, do this instead" =;-)  

Unfortunately your comment includes the words "you can only merge" ... which is where 
I get stuck because to appropriately perform the merge, I need a compare editor since
an 'automated' merge is likely to go off the rails quickly.

>> I have noticed that the same problem exists with plain text comparisons done in
>> this manner, so I get the feeling that I'm missing the boat on the workflow.  I looked
>> at this reference:
>>
>>  http://wiki.eclipse.org/EGit/User_Guide#Merging
>>
>> but I don't want to automatically merge content because doing so renders the
>> context completely invalid (it is XML from serialized Java objects).
>
>The Synchronize-view-merge/rebase-workflow is someting that need to be defined. Currently
>I don't have any idea how it can be done reasonably especially for new and old users. I
>only know that I don't want to limit anybody therefore I would rather propose something
>more git-like (not cvs/svn-like) workflow with (I hope) small amount of required knowledge
>to enter it.

Sounds reasonable.  I'm using git so I should expect to use a git like workflow.  My
question now becomes, at what point in the workflow do I get to invoke a compare editor
to allow me to perform the merge using a compare editor written to the team spec in Eclipse?

Rebasing my changes on top of 'incoming' changes will still involve a merge in the case
of a conflict, but at that point I don't want to resolve a file that has been already
pre-merged with <<<</>>>> content but rather I want to look at the two items that need
merging and pick what I need/want out.

Thanks,
 Thomas ... who is willing to put time into solving this issue