Author | SHA1 | Message | Date |
---|---|---|---|
Matthias Sohn | 8ada9048c5 |
Replace ExpectedException which was deprecated in junit 4.13
Change-Id: I64b0c057dd0a12aef2f3d56fa0c8a10e3b23fffd Signed-off-by: Matthias Sohn <matthias.sohn@sap.com> |
4 years ago |
Matthias Sohn | 5c5f7c6b14 |
Update EDL 1.0 license headers to new short SPDX compliant format
This is the format given by the Eclipse legal doc generator [1]. [1] https://www.eclipse.org/projects/tools/documentation.php?id=technology.jgit Bug: 548298 Change-Id: I8d8cabc998ba1b083e3f0906a8d558d391ffb6c4 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com> |
4 years ago |
Thomas Wolf | 447e107069 |
RenameBranchCommand: more consistent handling of short ref names
Several problems: * The command didn't specify whether it expected short or full names. * For the new name, it expected a short name, but then got confused if tags or both local and remote branches with the same name existed. * For the old name, it accepted either a short or a full name, but again got confused if a short name was given and a tag with the same name existed. With such an interface, one cannot use Repository.findRef() to reliably find the branch to rename. Use exactRef() for the new name as by the time the Ref is needed its full name is known. For determining the old Ref from the name, do the resolution explicitly: first try exactRef (assuming the old name is a full name); if that doesn't find anything, try "refs/heads/<old>" and "refs/remotes/<old>" explicitly. Throw an exception if the name is ambiguous, or if exactRef returned something that is not a branch (refs/tags/... or also refs/notes/...). Document in the javadoc what kind of names are valid, and add tests. A user can still shoot himself in the foot if he chooses exceptionally stupid branch names. For instance, it is still possible to rename a branch to "refs/heads/foo" (full name "refs/heads/refs/heads/foo"), but it cannot be renamed further using the new short name if a branch with the full name "refs/heads/foo" exists. Similar edge cases exist for other dumb branch names, like a branch with the short name "refs/tags/foo". Renaming using the full name is always possible. Bug: 542446 Change-Id: I34ac91c80c0a00c79a384d16ce1e727c550d54e9 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch> |
5 years ago |
David Pursehouse | 7ac182f4e4 |
Enable and fix 'Should be tagged with @Override' warning
Set missingOverrideAnnotation=warning in Eclipse compiler preferences which enables the warning: The method <method> of type <type> should be tagged with @Override since it actually overrides a superclass method Justification for this warning is described in: http://stackoverflow.com/a/94411/381622 Enabling this causes in excess of 1000 warnings across the entire code-base. They are very easy to fix automatically with Eclipse's "Quick Fix" tool. Fix all of them except 2 which cause compilation failure when the project is built with mvn; add TODO comments on those for further investigation. Change-Id: I5772061041fd361fe93137fd8b0ad356e748a29c Signed-off-by: David Pursehouse <david.pursehouse@gmail.com> |
7 years ago |
Thomas Wolf | aadbb158e1 |
Handle all values of branch.[name].rebase
BranchConfig treated this config property as a boolean, but git also allows the values "preserve" and "interactive". Config property pull.rebase also allows the same values. Replace private enum PullCommand.PullRebaseMode by new public enum BranchConfig.BranchRebaseMode and adapt all uses. Add a new setter to PullCommand. Note: PullCommand will treat "interactive" like "true", i.e., as a non-interactive rebase. Not sure how "interactive" should be handled. At least it won't balk on it. Bug: 499482 Change-Id: I7309360f5662b2c2efa1bd8ea6f112c63cf064af Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch> |
7 years ago |
Robin Rosenberg | 767be14f34 |
Move base test classes to the junit bundle for reuse for Java 7 tests
Change-Id: Iedb54eb9d8396bc3ae66d8754c1527fd9ca655f9 |
11 years ago |
Kevin Sawicki | fd0c468b7a |
Copy all branch configuration values when renaming
Previously only certain values were copied over which caused divergence in behavior between the JGit command and corresponding CGit command. Bug: 372051 Change-Id: I72a83215a679a713138da31f5ab838f14388d4bd Signed-off-by: Chris Aniszczyk <zx@twitter.com> |
12 years ago |