Skip to main content
Jump to: navigation, search

Difference between revisions of "EGit/New and Noteworthy/5.12"

m (API)
(UI: Staging View)
Line 3: Line 3:
 
== UI ==
 
== UI ==
  
<TBD>
+
=== Staging View ===
  
* Staging view shows info about conflict type.
+
The Staging View newly shows more information about conflicts during merging, rebasing, or cherry-picking commits:
* ''Replace With&rarr;Ours/Theirs'' removes the file and stages the deletion if the file was deleted in the ours or theirs commit. Simplifies resolving modify-delete conflicts.
+
* ''Replace With&rarr;Ours/Theirs'' in Package Explorer/Project Explorer.
+
  
 +
[[File:EGit 5.12 Staging Conflicts.png|alt="Screenshot of the Staging View with the new conflict type indicators highlighted."]]
 +
 +
Here, branch "side" was merged into branch "master", which resulted in conflicts. The staging view now indicates the ''type'' of conflict:
 +
 +
* '''M''' means "modified": both sides made conflicting modifications.
 +
* '''M/D''' means "modify/delete conflict": the file was modified on the 'ours' side of the merge, but deleted in the 'theirs' side.
 +
* '''D/M''' means "delete/modify conflict": the file was deleted on our side, but modified on their side.
 +
* '''A''' means "conflicting additions": the file was added on both sides (with respect to the merge base), but the two file versions conflict.
 +
 +
 +
The 'ours' side is HEAD before the merge, in the example branch "master", while 'theirs' is the commit being merged into 'ours', in the example branch "side". There are tags named 'ours' and 'theirs' in the history view for this example to show this clearly. (These tags were created manually; EGit does not create such tags when a merge is done.)
 +
 +
The ''Replace With&rarr;Ours/Theirs'' command in the context menu of such a conflicting file has been improved. For delete/modify or modify/delete conflicts it will now remove the file and stage the deletion if the file was deleted in the chosen side. (In the example, since the file was deleted in the 'theirs' side, ''Replace With&rarr;Theirs'' would delete the file.)
 +
 +
Additionally, ''Replace With&rarr;Ours/Theirs'' is now also available in the context menu for conflicting files in the Package or Project Explorer.
 +
 +
=== Merge Editor ===
  
 
<Planned>
 
<Planned>

Revision as of 15:19, 30 May 2021

EGit

UI

Staging View

The Staging View newly shows more information about conflicts during merging, rebasing, or cherry-picking commits:

"Screenshot of the Staging View with the new conflict type indicators highlighted."

Here, branch "side" was merged into branch "master", which resulted in conflicts. The staging view now indicates the type of conflict:

  • M means "modified": both sides made conflicting modifications.
  • M/D means "modify/delete conflict": the file was modified on the 'ours' side of the merge, but deleted in the 'theirs' side.
  • D/M means "delete/modify conflict": the file was deleted on our side, but modified on their side.
  • A means "conflicting additions": the file was added on both sides (with respect to the merge base), but the two file versions conflict.


The 'ours' side is HEAD before the merge, in the example branch "master", while 'theirs' is the commit being merged into 'ours', in the example branch "side". There are tags named 'ours' and 'theirs' in the history view for this example to show this clearly. (These tags were created manually; EGit does not create such tags when a merge is done.)

The Replace With→Ours/Theirs command in the context menu of such a conflicting file has been improved. For delete/modify or modify/delete conflicts it will now remove the file and stage the deletion if the file was deleted in the chosen side. (In the example, since the file was deleted in the 'theirs' side, Replace With→Theirs would delete the file.)

Additionally, Replace With→Ours/Theirs is now also available in the context menu for conflicting files in the Package or Project Explorer.

Merge Editor

<Planned>

  • Merge Editor improvements

API

EGit 5.12 offers new API giving third-party bundles access to git information.

The org.eclipse.egit.core bundle offers the following new interfaces and classes:

  • org.eclipse.egit.core.info.GitInfo: this accessor interface can be obtained via adaptation using Adapters.adapt(someObject, GitInfo.class);. Via the interface, clients can determine the JGit Repository the item is in, its path within the repository, whether it is from the working tree, the git index, or a commit (and if so, which commit), and what its git state is.
    • someObject can be anything; in particular it could be an org.eclipse.core.resources.IFile or an org.eclipse.team.core.history.IFileRevision or an org.eclipse.compare.ITypedElement.
    • If GitInfo.getRepository() == null, someObject is not in an EGit-managed git repository.
    • If the adaptation itself returns null, the item is either not in an EGit-managed git repository, or EGit doesn't know how to provide a GitInfo for someObject.
  • org.eclipse.egit.core.info.GitItemState: this can be obtained via GitInfo.getGitState() and tells the git state for the item in the git repository at that path. This can be used to determine whether the item has staged changes in the index, whether it was modified in the working tree only, whether it is in a conflict state, and so on. (Client code can also obtain such information given the repository and the git path by using JGit directly and looking up the information directly in the git index. GitItemState may be more efficient since it uses an optimized cache inside EGit that EGit uses internally, too.)
  • org.eclipse.egit.core.revisions.FileRevisionFactory exposes factory methods to create org.eclipse.team.core.history.IFileRevision objects for items in the git index or in a git commit. This is useful if client code wants to compare items from a git repository.
  • org.eclipse.egit.core.util.RevCommitUtils offers some utility methods; in particular a method to determine the "theirs" commit in a conflict.


Existing client code is strongly encouraged to use this new API instead of accessing EGit internal non-API classes directly.

Other Changes

EGit 5.12 includes some less noticeable improvements in the UI, plus a number of bug fixes. The complete list of new features and bug fixes is available in the release notes.

Contributors

The following X developers worked on this release:

<TBD: list of contributors, number>

See Also

See also the new features in JGit for additional information.

Back to the top