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

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. 

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].

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.

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.

We are planning to submit the first patches during the month of october.

Last but not least, this work is sponsored by Ericsson and we would like to thank them for that.

Best regards,

Le 12 sept. 2013 à 21:52, Matthias Sohn <matthias.sohn@xxxxxxxxx> a écrit :

ok, let's plan to ship 3.2 with Kepler SR2
I updated the project plans accordingly

On Thu, Sep 12, 2013 at 5:35 PM, Chris Aniszczyk <caniszczyk@xxxxxxxxx> wrote:
My preference is 3.2.0

On Wed, Sep 11, 2013 at 6:59 AM, Matthias Sohn <matthias.sohn@xxxxxxxxx> wrote:
good question, according to [1] we can ship a minor release with a SR if the minor
release was released 1 month before the RC1 of the SR, for Kepler SR2 this means
we would have to release before Christmas (Dec 24), this means we could ship 3.2.0.

So we have the option to either ship 3.2.0 or 3.0.3 with Kepler SR2. 
Opinions ?



On Wed, Sep 11, 2013 at 1:33 PM, Mikaël Barbero <mikael.barbero@xxxxxxxxx> wrote:
Hi Matthias,

What is the plan regarding Kepler SR2? Will it be 3.2.0 from Luna M4 or 3.0.3?


Le 11 sept. 2013 à 13:01, Matthias Sohn <matthias.sohn@xxxxxxxxx> a écrit :

I have setup a tentative release schedule until Luna:

3.1.0:  Oct 2, 2013 (Luna M2
3.2.0:  Dec 18, 2013 (Luna M4)
3.3.0:  Feb 28, 2014 (Luna M6)
4.0.0:  June 25, 2014 (Luna)

and added a tentative plan until 4.0.0 here
this draft lists new features already cooking in Gerrit and those I know we
at SAP plan to work on.

Committers feel free to update the plan with features you plan to implement until Luna.
Add a hint until which release you plan the feature to be ready.

Contributors let us know if you want to see cool new features you plan to implement
until Luna in the project plan.

egit-dev mailing list

jgit-dev mailing list


Chris Aniszczyk
+1 512 961 6719

Back to the top