|Re: [egit-dev] Should I be able to Merge content when Synchronizing?|
If you right-click on a conflicted resource, there is a mergetool
entry in the Team submenu.
On Tue, Apr 5, 2011 at 23:08, Bernard Leach <leachbj@xxxxxxxxxxxxxxxx> wrote:
> Since there is a conflict it sounds like you want to hook into the merge-tool's compare editor. With c git command line you run git mergetool and specify your custom merge app. I'm not an egit dev so not sure what's possible there.
> On 06/04/2011, at 4:11, "Thomas Fletcher" <thomas@xxxxxxxxxxxxxxxxx> wrote:
>>> -----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:
>>>> 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.
>> Thomas ... who is willing to put time into solving this issue
Back to the top