Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jgit-dev] [egit-dev] Plan for upcoming releases
Wow, that's great news that somebody approaches this feature of merge drivers in JGit.

Since I wrote most of JGits ResolveMerger & MergeAlgorithm class and I can offer my help whenever there is doubt about how to refactor this code. We should clearly differentiate between changes to MergeStrategies (ours, theirs, resolve, recursive) and that component which does the content merge (a merge driver a native git, in JGit it's the MergeAlgorithm class).  But as I can see from your previous mail you are well aware about that and I guess what you want is mainly alternative implementations of the MergeAlgorithm class.

But, before exchanging ideas to long on the mailing list with mails with the generic subject "Plan for upcoming releases" I would suggest that you open a bug in bugs.eclipse.org for jgit and that we continue discussing there.

Ciao
  Chris



Ciao
  Chris


On Tue, Sep 24, 2013 at 11:58 PM, Mikaël Barbero <mikael.barbero@xxxxxxxxx> wrote:
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 


_______________________________________________
jgit-dev mailing list
jgit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jgit-dev


Back to the top