aboutsummaryrefslogtreecommitdiffstats
path: root/org.eclipse.jgit/src/org/eclipse/jgit/api/RebaseCommand.java
Commit message (Collapse)AuthorAgeFilesLines
* RebaseCommand: use java.time instead of java.util.Date APIMatthias Sohn2024-12-291-8/+13
| | | | Change-Id: I3004d5b586b674e81cc76d0b01cef424d0b1f7f8
* [errorprone] Fix error pattern JdkObsoleteMatthias Sohn2024-04-291-3/+2
| | | | | | See https://errorprone.info/bugpattern/JdkObsolete Change-Id: Id105e2695eb64523bd217f507bf95f909bc6b348
* RebaseCommand: fix stopping on root commit conflictsThomas Wolf2024-01-281-5/+9
| | | | | | | | | If rebasing runs into a conflict when applying a root commit from an independent branch, there is no parent commit. Write an empty patch file in that case like C git does. Bug: jgit-6 Change-Id: I315313673d2abf29639d7d96c958d599961ba276 Signed-off-by: Thomas Wolf <twolf@apache.org>
* RebaseCommand: return correct status on stash apply conflictsThomas Wolf2023-10-131-12/+19
| | | | | | | | Ensure that also the fast-forward cases return status STASH_APPLY_CONFLICTS when applying the stash produces conflicts. Bug: 582526 Change-Id: Ib989ff431dca6e301eb05156ca054a7115fa6ad5 Signed-off-by: Thomas Wolf <twolf@apache.org>
* Fix all Javadoc warnings and fail on themAntoine Musso2023-06-161-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes all the javadoc warnings, stops ignoring doclint 'missing' category and fails the build on javadoc warnings for public and protected classes and class members. Since javadoc doesn't allow access specifiers when specifying doclint configuration we cannot set `-Xdoclint:all,-missing/private` hence there is no simple way to skip private elements from doclint. Therefore we check javadoc using the Eclipse Java compiler (which is used by default) and javadoc configuration in `.settings/org.eclipse.jdt.core.prefs` files. This allows more fine grained configuration. We can reconsider this when javadoc starts supporting access specifiers in the doclint configuration. Below are detailled explanations for most modifications. @inheritDoc =========== doclint complains about explicits `{@inheritDoc}` when the parent does not have any documentation. As far as I can tell, javadoc defaults to inherit comments and should only be used when one wants to append extra documentation from the parent. Given the parent has no documentation, remove those usages which doclint complains about. In some case I have moved up the documentation from the concrete class up to the abstract class. Remove `{@inheritDoc}` on overriden methods which don't add additional documentation since javadoc defaults to inherit javadoc of overridden methods. @value to @link =============== In PackConfig, DEFAULT_SEARCH_FOR_REUSE_TIMEOUT and similar are forged from Integer.MAX_VALUE and are thus not considered constants (I guess cause the value would depends on the platform). Replace it with a link to `Integer.MAX_VALUE`. In `StringUtils.toBoolean`, @value was used to refer to the `stringValue` parameter. I have replaced it with `{@code stringValue}`. {@link <url>} to <a> ==================== @link does not support being given an external URL. Replaces them with HTML `<a>`. @since: being invalid ===================== org.eclipse.jgit/src/org/eclipse/jgit/util/Equality.java has an invalid tag `@since: ` due to the extra `:`. Javadoc does not complain about it with version 11.0.18+10 but does with 11.0.19.7. It is invalid regardless. invalid HTML syntax =================== - javadoc doesn't allow <br/>, <p/> and </p> anymore, use <br> and <p> instead - replace <tt>code</tt> by {@code code} - <table> tags don't allow summary attribute, specify caption as <caption>caption</caption> to fix this doclint visibility issue ======================== In the private abstract classes `BaseDirCacheEditor` and `BasePackConnection` links to other methods in the abstract class are inherited in the public subclasses but doclint gets confused and considers them unreachable. The HTML documentation for the sub classes shows the relative links in the sub classes, so it is all correct. It must be a bug somewhere in javadoc. Mute those warnings with: @SuppressWarnings("doclint:missing") Misc ==== Replace `<` and `>` with HTML encoded entities (`&lt; and `&gt;`). In `SshConstants` I went enclosing a serie of -> arrows in @literal. Additional tags =============== Configure maven-javad0c-plugin to allow the following additional tags defined in https://openjdk.org/jeps/8068562: - apiNote - implSpec - implNote Missing javadoc =============== Add missing @params and descriptions Change-Id: I840056389aa59135cfb360da0d5e40463ce35bd0 Also-By: Matthias Sohn <matthias.sohn@sap.com>
* Support rebasing independent branchesThomas Wolf2023-04-291-11/+19
| | | | | | | | | With completely independent branches, there is no merge base. In this case, the list of commits must include the root commit of the branch to be rebased. Bug: 581832 Change-Id: I0f5bdf179d5b07ff09f1a274d61c7a0b1c0011c6 Signed-off-by: Thomas Wolf <twolf@apache.org>
* Change config pull.rebase=preserve to pull.rebase=mergesPavel Salamon2023-02-281-2/+2
| | | | | | | | | | | | | | | The native git option to preserve merge commits during rebase has been changed from pull.rebase=preserve to pull.rebase=merges. This changeset in jgit makes the same config change. The old "preserve" option is no longer recognized and is replaced by new option called "merges". This makes jgit's rebase configuration compatible with native git versions 2.34 and newer where the old "preserve" option has been removed. Change-Id: Ic07ff954e258115e76465a1593ef3259f4c418a3
* Use git config core.commentCharThomas Wolf2022-03-261-25/+58
| | | | | | | | | | | | | This concerns committing, creating merge conflict messages and creating and editing squash messages. In a squash message, once the comment character has been determined initially is always the first character. Note that if core.commentChar=auto and there is a sequence of squashes, it may be necessary to change the comment character when a new message is added. Bug: 579325 Change-Id: Idca19284a0240cd322e7512ea299a03658e1b2c1 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* [rebase] InteractiveHandler2: handle Gerrit Change-IdsThomas Wolf2022-02-041-6/+27
| | | | | | | | | | | | | Add a way for the handler to tell whether the commit should generate a Gerrit Change-Id. Augment the ModifyResult interface, and set the flag on the CommitCommand. This enables users to have a Change-ID be generated when squashing or rewording commits. A possibly already existing Change-Id will remain unchanged. Bug: 440211 Change-Id: I66a72e0646876d162a7011235cca969e20acf060 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* RebaseCommand: fix commit message in "fixup" caseThomas Wolf2022-02-021-25/+29
| | | | | | | | | | | | | | | | | | | JGit accumulated in MESSAGE_FIXUP commit messages of a fixup sequence, just like it did in MESSAGE_SQUASH, and on the last step of a sequence of fixups used that file, after stripping all comment lines, as the commit message. That also stripped any lines from the original commit message that happened to start with the comment character. This is not how this is supposed to work. MESSAGE_FIXUP must contain the original commit message of the base commit that is amended, and the file contains the verbatim commit message for the final fixup.[1] Change the implementation accordingly, and add new tests. [1] https://github.com/git/git/blob/df3c41adeb/sequencer.c#L86 ff. Bug: 513726 Change-Id: I885a2b7f10d6c74460a8693aa6cbf867ee0494a1 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* RebaseCommand: better commit message rewordingThomas Wolf2022-01-311-27/+110
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Respect git config commit.cleanup for rewording. Note that by default this is CleanupMode.STRIP, whereas before this change, JGit would take the reworded message verbatim. Squashing was the only place in JGit where it automatically and unconditionally removed comment lines from commit messages. In other places it didn't do so, and client code needed to do so. Unconditionally removing comments is problematic if the commit message _should_ contain some line starting with a hash, which can easily occur with the way Github, Gitlab, and other git web servers link to issues or PRs: they all allow the short-hand "#<number>". Introduce a new InteractiveHandler2 extension interface, which can return the edited message _and_ a clean-up mode. This way, client code can decide on its own how to clean the message, and if JGit shouldn't do any further cleaning, it can return CleanupMode.VERBATIM. Or CleanupMode.WHITESPACE. (In the case of SQUASH, it is then of course the client's responsibility to remove the squash comment lines.) If the old InteractiveHandler interface is used, CleanupMode.STRIP is applied unconditionally for squashing, as before. Bug: 578173 Change-Id: Ia0040c247884e684587dd45d6cb85f8b72a4b876 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* Implement ours/theirs content conflict resolutionThomas Wolf2021-04-191-5/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | Git has different conflict resolution strategies: * There is a tree merge strategy "ours" which just ignores any changes from theirs ("-s ours"). JGit also has the mirror strategy "theirs" ignoring any changes from "ours". (This doesn't exist in C git.) Adapt StashApplyCommand and CherrypickCommand to be able to use those tree merge strategies. * For the resolve/recursive tree merge strategies, there are content conflict resolution strategies "ours" and "theirs", which resolve any conflict hunks by taking the "ours" or "theirs" hunk. In C git those correspond to "-Xours" or -Xtheirs". Implement that in MergeAlgorithm, and add API to set and pass through such a strategy for resolving content conflicts. * The "ours/theirs" content conflict resolution strategies also apply for binary files. Handle these cases in ResolveMerger. Note that the content conflict resolution strategies ("-X ours/theirs") do _not_ apply to modify/delete or delete/modify conflicts. Such conflicts are always reported as conflicts by C git. They do apply, however, if one side completely clears a file's content. Bug: 501111 Change-Id: I2c9c170c61c440a2ab9c387991e7a0c3ab960e07 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Fix DateRevQueue tie breaks with more than 2 elementsAdithya Chakilam2021-02-071-8/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DateRevQueue is expected to give out the commits that have higher commit time. But in case of tie(same commit time), it should give the commit that is inserted first. This is inferred from the testInsertTie test case written for DateRevQueue. Also that test case, right now uses just two commits which caused it not to fail with the current implementation, so added another commit to make the test more robust. By fixing the DateRevQueue, we would also match the behaviour of LogCommand.addRange(c1,c2) with git log c1..c2. A test case for the same is added to show that current behaviour is not the expected one. By fixing addRange(), the order in which commits are applied during a rebase is altered. Rebase logic should have never depended upon LogCommand.addRange() since the intended order of addRange() is not the order a rebase should use. So, modify the RebaseCommand to use RevWalk directly with TopoNonIntermixSortGenerator. Add a new LogCommandTest.addRangeWithMerge() test case which creates commits in the following order: A - B - C - M \ / -D- Using git 2.30.0, git log B..M outputs: M C D LogCommand.addRange(B, M) without this fix outputs: M D C LogCommand.addRange(B, M) with this fix outputs: M C D Change-Id: I30cc3ba6c97f0960f64e9e021df96ff276f63db7 Signed-off-by: Adithya Chakilam <achakila@codeaurora.org>
* Using for-each loop in jdtLars Vogel2020-02-281-2/+1
| | | | | | | Running the JDT cleanup action for using a for-each loop on jgit Change-Id: Ie724d8bbdff786ab0167089e90a9914a8135103c Signed-off-by: Lars Vogel <Lars.Vogel@vogella.com>
* Merge branch 'stable-5.6'Matthias Sohn2020-02-221-2/+3
|\ | | | | | | | | | | | | | | | | | | | | | | | | * stable-5.6: Revert "Prepend hostname to subsection used to store file timestamp resolution" SimilarityRenameDetector: Fix inconsistent indentation Use indexOf(char) and lastIndexOf(char) rather than String versions Reorder modifiers to follow Java Language Specification GitmoduleEntry: Remove redundant import of class from same package Remove redundant "static" qualifier from enum declarations Change-Id: Ibb66bef7e8373f81e3e653c9843d986243446d68 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
| * Use indexOf(char) and lastIndexOf(char) rather than String versionsDavid Pursehouse2020-02-191-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | An indexOf or lastIndexOf call with a single letter String can be made more performant by switching to a call with a char argument. Found with SonarLint. As a side-effect of this change, we no longer need to suppress the NON-NLS warnings. Change-Id: Id44cb996bb74ed30edd560aa91fd8525aafdc8dd Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* | Update EDL 1.0 license headers to new short SPDX compliant formatMatthias Sohn2020-01-041-38/+5
|/ | | | | | | | | | 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>
* Enable and fix "Statement unnecessarily nested within else clause" warningsDavid Pursehouse2019-10-171-9/+9
| | | | | | | | | | | | | | | Since [1] the gerrit project includes jgit as a submodule, and has this warning enabled, resulting in 100s of warnings in the console. Also enable the warning here, and fix them. At the same time, add missing braces around adjacent and nearby one-line blocks. [1] https://gerrit-review.googlesource.com/c/gerrit/+/227897 Change-Id: I81df3fc7ed6eedf6874ce1a3bedfa727a1897e4c Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* [error prone] suppress AmbiguousMethodReference in AnyObjectIdMatthias Sohn2019-08-081-1/+1
| | | | | | | | | | Move the implementation of the static equals() method to a new method and suppress the error. Deprecate the old method to signal that we intend to remove it in the next major release. See https://errorprone.info/bugpattern/AmbiguousMethodReference Change-Id: I5e29c97f4db3e11770be589a6ccd785e2c9ac7f2 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Consistently use "!isEmpty()" to detect non-empty listDavid Pursehouse2019-06-071-2/+2
| | | | | | | | | | Replace "size() > 0" with "!isEmpty()" where appropriate. In the Status implementation we can drop the check; the subsequent loop will only execute when the list is non-empty anyway. Change-Id: I355aff551a603373e702a9d44304f087b476263c Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* Use isEmpty() instead of size()==0 where possibleCarsten Hammer2019-04-131-1/+1
| | | | | Change-Id: I97f1367a2ea9f1f6146e264c27c3981b842f2a26 Signed-off-by: Carsten Hammer <carsten.hammer@t-online.de> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Join catch sections using multicatchCarsten Hammer2019-04-131-7/+2
| | | | | Change-Id: I1a9112e6a4f938638c599b489cb0858eca27ab91 Signed-off-by: Carsten Hammer <carsten.hammer@t-online.de> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* RebaseCommand: tighten check for --preserve-merges on --continueThomas Wolf2019-02-261-1/+5
| | | | | | | | | | | | | With native git, .git/rebase-merge/rewritten exists actually in two different cases: * as a file in git rebase --merge recording OIDs for copying notes * as a directory in git rebase --preserve-merges Add a comment, and check for isDirectory() instead of exists(). Bug: 511487 Change-Id: I6a3317b4234d4f41c41b3004cdc7ea0abf2c6223 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* RebaseCommand: use orig-head to abortThomas Wolf2019-02-261-2/+15
| | | | | | | | | | | | | Aborting a rebase used ORIG_HEAD to reset. Strictly speaking this is not correct, since other commands run during the rebase (for instance, when the rebase stopped on a conflict) might have changed ORIG_HEAD. Prefer the OID recorded in the orig-head file, falling back to the older "head" file if "orig-head" doesn't exist, and use ORIG_HEAD only if neither exists. Bug: 511487 Change-Id: Ifa99221bb33e4e4754377f9b8f46e76c8936e072 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* RebaseCommand: use orig-head in addition to headThomas Wolf2019-02-261-1/+5
| | | | | | | | | | | | Since 2011-02-10 (i.e., git 1.7.6)[1] native git uses "orig-head" for REBASE_HEAD. JGit was still using "head". Currently native git has a legacy fall-back for reading this, but for how long? Let's write to both. Note that JGit never reads this file. [1] https://github.com/git/git/commit/84df4560 Bug: 511487 Change-Id: Id3742bf9bbc0001d850e801b26cc8880e646abfc Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* RebaseCommand: fix ONTO_NAME, and --preserve-merges is interactiveThomas Wolf2019-02-261-6/+26
| | | | | | | | | | | | | | | | | | ONTO_NAME must be "onto_name", not "onto-name". For native git, --preserve-merges is an interactive mode. Create the INTERACTIVE marker file, otherwise a native git rebase --continue will fall back into rebase --merge mode before git 2.19.0 since it started looking for the REWRITTEN directory to make the distinction only then.[1] This allows a JGit interactive rebase to be continued via native git rebase --continue. [1] https://github.com/git/git/commit/6d98d0c0 Bug: 511487 Change-Id: I13850e0fd96ac77d03fbb581c8790d76648dbbc6 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* Deprecate Constants.CHARACTER_ENCODING in favor of StandardCharsets.UTF_8David Pursehouse2018-09-301-4/+5
| | | | | Change-Id: I621ba174235a6fb56236e54d24bce704bb5afb28 Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* RebaseCommand: Remove unnecessary fall through commentsJonathan Nieder2018-08-041-2/+0
| | | | | | | | | | | | | | | | | | | It's easier to read a list of cases case A: case B: case C: ... do something ...; break; without intervening "// fall through" lines separating the cases. This also makes it clearer that JGit uses "$FALL-THROUGH$", not "fall through", to suppress fallthrough warnings in switch statements. Eclipse does not pay attention to the second comment style. Change-Id: I5279a727aee2868854d06bfcaac8cb8186b4299e Signed-off-by: Jonathan Nieder <jrn@google.com>
* Open auto-closeable resources in try-with-resourceDavid Pursehouse2018-03-131-8/+2
| | | | | | | | | | | | | | | | | | | | When an auto-closeable resources is not opened in try-with-resource, the warning "should be managed by try-with-resource" is emitted by Eclipse. Fix the ones that can be silenced simply by moving the declaration of the variable into a try-with-resource. In cases where we explicitly call the close() method, for example in tests where we are testing specific behavior caused by the close(), suppress the warning. Leave the ones that will require more significant refcactoring to fix. They can be done in separate commits that can be reviewed and tested in isolation. Change-Id: I9682cd20fb15167d3c7f9027cecdc82bc50b83c4 Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* Progress reporting for checkoutMarkus Duft2018-01-231-0/+3
| | | | | | | | | | | | | | The reason for the change is LFS: when using a lot of LFS files, checkout can take quite some time on larger repositories. To avoid "hanging" UI, provide progress reporting. Also implement (partial) progress reporting for cherry-pick, reset, revert which are using checkout internally. The feature is also useful without LFS, so it is independent of it. Change-Id: I021e764241f3c107eaf2771f6b5785245b146b42 Signed-off-by: Markus Duft <markus.duft@ssi-schaefer.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Fix javadoc in org.eclipse.jgit annotations and api packagesMatthias Sohn2017-12-181-17/+40
| | | | Change-Id: I2761ea91f8dfed16ea54e7a6646af03a30c15ec9 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* ReflogWriter: Align auto-creation defaults with C gitDave Borowitz2017-09-301-0/+1
| | | | | | | | | | Per git-config(1), core.logAllRefUpdates auto-creates reflogs for HEAD and for refs under heads, notes, tags, and for HEAD. Add notes and remove stash from ReflogWriter#shouldAutoCreateLog. Explicitly force writing reflogs for refs/stash at call sites, now that this is supported. Change-Id: I3a46d2c2703b7c243e0ee2bbf6948279800c485c
* Don't try to strip new line if the message buffer is emptyAndrey Loskutov2017-03-151-2/+6
| | | | | | Bug: 513726 Change-Id: I0e7c19f8883b93bad1b9de166f671d28f3e9c240 Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
* Enable and fix warnings about redundant specification of type argumentsDavid Pursehouse2017-02-201-7/+7
| | | | | | | | | | Since the introduction of generic type parameter inference in Java 7, it's not necessary to explicitly specify the type of generic parameters. Enable the warning in Eclipse, and fix all occurrences. Change-Id: I9158caf1beca5e4980b6240ac401f3868520aad0 Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* Enable and fix 'Should be tagged with @Override' warningDavid Pursehouse2017-02-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | 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>
* [infer] Fix resource leaks in RebaseCommandMatthias Sohn2016-12-181-7/+9
| | | | | Bug: 509385 Change-Id: I9fbdfda59f7bc577aab55dc92ff897b00b5cb050 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Implement auto gcMatthias Sohn2016-10-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the auto option, gc checks whether any housekeeping is required; if not, it exits without performing any work. Some JGit commands run gc --auto after performing operations that could create many loose objects. Housekeeping is required if there are too many loose objects or too many packs in the repository. If the number of loose objects exceeds the value of the gc.auto option jgit's GC consolidates all existing packs into a single pack (equivalent to -A option), whereas git-core would combine all loose objects into a single pack using repack -d -l. Setting the value of gc.auto to 0 disables automatic packing of loose objects. If the number of packs exceeds the value of gc.autoPackLimit, then existing packs (except those marked with a .keep file) are consolidated into a single pack by using the -A option of repack. Setting gc.autoPackLimit to 0 disables automatic consolidation of packs. Like git the following jgit commands run auto gc: - fetch - merge - rebase - receive-pack The auto gc for receive-pack can be suppressed by setting the config option receive.autogc = false Change-Id: I68a2a051b39ec2c53cb7c4b8f6c596ba65eeba5d Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Replace use of deprecated method Repository.getRef()Matthias Sohn2016-05-311-3/+3
| | | | Change-Id: Iecf2b8deafc4991cc3333702fb9fa0638be7b914 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Add progress monitor to MergerLaurent Delaigue2016-01-211-0/+2
| | | | | | | | | | | | Monitoring progress of merges can be useful for users for large repositories or complex merge processes that take some time. This enables setting a monitor. Existing merge implementations in jgit do not yet report progress if a monitor is set. This will be added in a later change. Change-Id: I17b978b3fc91750dd88649638b90a46820a0877c Signed-off-by: Laurent Delaigue <laurent.delaigue@obeo.fr> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Null-annotated Ref class and fixed related compiler errorsAndrey Loskutov2015-12-151-5/+14
| | | | | | | | | This change fixes all compiler errors in JGit and replaces possible NPE's with either appropriate exceptions, avoiding multiple "Nullable return" method calls or early returning from the method. Change-Id: I24c8a600ec962d61d5f40abf73eac4203e115240 Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
* Null-annotated Repository class and fixed related compiler errorsAndrey Loskutov2015-11-251-5/+6
| | | | | | | | | | | | | | | | | | | | | | org.eclipse.jgit.lib.Repository class is an example of the API which should be written with Java 8 java.util.Optional<T> type. Unfortunately this API is already released and widely used. The good clients are currently doing their best with checking return values for null and bad clients do not know how bad their code is. I've tried not to change any logic and to be as less intrusive as possible. Most of the JGit code was well prepared to this, only few classes needed some smaller fixes. This change fixes all compiler errors in JGit and replaces possible NPE's with either appropriate exceptions, avoiding multiple "Nullable return" method calls or early returning from the method. Because annotating getDirectory() and getFS() as Nullable would cause lot of additional changes in JGit and EGit they are postponed. Change-Id: Ie8369d2c9c5fac5ce83b3b1b9bc217d7b55502a3 Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
* Raise error if FileNotFoundException is caught for an existing fileMatthias Sohn2015-11-241-0/+3
| | | | | | | | | | | | File, FileInputStream and friends may throw FileNotFoundException even if the file is existing e.g. when file permissions don't allow to access the file content. In most cases this is a severe error we should not suppress hence rethrow the FileNotFoundException in this case. This may also fix bug 451508. Bug: 451508 Change-Id: If4a94217fb5b7cfd4c04d881902f3e86193c7008 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Handle null in ProgressMonitor settersJonathan Nieder2015-06-111-0/+3
| | | | | | | | | | | These commands' monitor fields can never be null unless someone passes null to setProgressMonitor. Anyone passing null probably meant to disable the ProgressMonitor, so do that (by falling back to NullProgressMonitor.INSTANCE) instead of saving a null and eventually producing NullPointerException. Change-Id: I63ad93ea8ad669fd333a5fd40880e7583ba24827 Signed-off-by: Jonathan Nieder <jrn@google.com>
* Externalize translatable texts in org.eclipse.jgitMatthias Sohn2015-05-261-6/+9
| | | | Change-Id: Ibf4c299f9d203c78cae79e61f88d4bea60ea2795 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Use AutoClosable to close resources in bundle org.eclipse.jgitMatthias Sohn2015-05-211-113/+127
| | | | | | | - use try-with-resource where possible - replace use of deprecated release() by close() Change-Id: I0f139c3535679087b7fa09649166bca514750b81 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Fix typo in reflog message written by RebaseCommand.tryFastForward()Matthias Sohn2015-05-151-1/+1
| | | | Change-Id: I1ad544f2b5673ed3b4a2206b5eb4ce20fd3c86d2 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Make RepositoryState.REBASING_MERGE reachable again.Laurent Delaigue2015-03-271-1/+3
| | | | | | | | | | | If a non interactive rebase is launched, stopping after a conflict should set the repository state to RepositoryState.REBASING_MERGE instead of RepositoryState.REBASING_INTERACTIVE. Bug: 452623 Change-Id: Ie885aab6d71dabd158a718af0d14fff643c9b850 Also-by: Arthur Daussy <arthur.daussy@obeo.fr> Signed-off-by: Laurent Delaigue <laurent.delaigue@obeo.fr> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Support for the pre-commit hookLaurent Goubet2015-02-021-5/+4
| | | | | | | | | Introduce support for the pre-commit hook into JGit, along with the --no-verify commit command option to bypass it when rebasing / cherry-picking. Change-Id: If86df98577fa56c5c03d783579c895a38bee9d18 Signed-off-by: Laurent Goubet <laurent.goubet@obeo.fr> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* RebaseCommand should ignore submodule modificationsChristian Halstrick2014-11-031-1/+2
| | | | | | | | | | | | | | | Before a rebase happens the RebaseCommand checks that the working tree is clean. We don't want to start a rebase on a dirty working tree. If the working tree is dirty a rebase should not be allowed. But RebaseCommand should ignore modifications done to submodules. E.g. if a submodules HEAD points to <x> but the root repository has in index that the submodule should point to <y> then this should not prohibit a rebase. Also native git allows a rebase in this case. Since jgit's StatusCommand has learned to ignore submodule changes this is now used by the RebaseCommand to determine the repository state correctly. Bug: 446922 Change-Id: I487bf7484dca3f5501e6e514584e2871524eea19
* Rename local variables/parameters to remove warnings about hidingRobin Rosenberg2014-09-041-10/+10
| | | | Change-Id: I73f38492b6a2e7fd6e77005efd0a8a8c65763e74
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-09 17:20:24 +0000