Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [egit-dev] [jgit-dev] Plan for upcoming releases
Thank you for welcoming the news. Regarding the merge strategy, we definitely agree. I was talking about resolver merger because it is where most of the content merge actually happens and this is where we have some changes to do. We don't plan to change anything related to strategy handling.

Best regards,
Mikael

Le 24 sept. 2013 à 23:17, Matthias Sohn <matthias.sohn@xxxxxxxxx> a écrit :

On Tue, Sep 24, 2013 at 9:59 AM, Mikaël Barbero <mikael.barbero@xxxxxxxxx> wrote:
Dear [EJ]Git Teams,

Regarding the cool new features, we (Obeo) are planning to implement preliminary support for merge drivers within JGit [1, 2]. I'm only speaking about preliminary support because we only plan to support programmatic contributions of merge drivers, not through gitattributes files. Obviously, we will implement this feature with gitattributes in mind so that this will be easy to plug each others when JGit will support those files. 
 
that's great news :-)
 
This work already let us find and fix out some bugs in JGit like [5]. It still requires some refactoring within ResolveMerger class to extract the text-only merge support and to implement it as a default merge driver. We are also planning to add a binary merge driver that will not add angle brackets in case of conflicts within binary files. It will corresponds to binary builtin merge driver wihthin CGit as stated in [2].

I think recursive merge should stay the default merge strategy not resolve merge (which has 
all the basics but can't cope with criss-cross merges)
 
Built-in merge drivers

There are a few built-in low-level merge drivers defined that can be asked for via the merge attribute.
  • text
    • Usual 3-way file level merge for text files. Conflicted regions are marked with conflict markers <<<<<<<, ======= and >>>>>>>. The version from your branch appears before the ======= marker, and the version from the merged branch appears after the ======= marker.
  • binary
    • Keep the version from your branch in the work tree, but leave the path in the conflicted state for the user to sort out.

Our ultimate goal is to add an EGit merge driver that will be able to call Eclipse Team merge API [3] to support logical model merge [4]. This will be done in another contribution, to EGit.


I updated the project plans and included your planned contributions
 
Laurent Goubet and myself will be pleased to talk with you about these features. Also, I will be at Eclipse Con Europe at the end of october, so if some of you guys are there, I will be glad to meet you.

looking forward to see you at EclipseCon Europe
 

--
Matthias 

Back to the top