The Java Language Specification recommends listing modifiers in
the following order:

1. Annotations
2. public
3. protected
4. private
5. abstract
6. static
7. final
8. transient
9. volatile
10. synchronized
11. native
12. strictfp

Not following this convention has no technical impact, but will reduce
the code's readability because most developers are used to the standard
order.

This was detected using SonarLint.

Change-Id: I9cddecb4f4234dae1021b677e915be23d349a380
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>

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>

A merging pull on an unborn branch was already supported. But a
rebasing pull failed. If the user has pull.rebase = true in his
user config, the pull would try to rebase. Rebasing needs a parent
commit, though. Native git handles this case:

  git init
  git remote add origin <URI>
  git pull --rebase origin master

Check up front in PullCommand for the unborn head and just do a
checkout in this case. MergeCommand already has similar code.

Bug: 544965
Change-Id: I1277e1ac0b0364b4623fd791f3d6b07bd5f58fca
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>

Change-Id: I2761ea91f8dfed16ea54e7a6646af03a30c15ec9
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Bug: 517847
Change-Id: I70d12dbe347a3d7a3528687ee04e52a2052bfb93
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

When the configuration entry 'pull.ff' exists the merge of the pull will
use the value as fast forward option.

Bug: 474174
Change-Id: Ic8db2f00095ed81528667b064ff523911e6c122e
Signed-off-by: Mattias Neuling <neuling@dakosy.de>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Annotate the `recurse` parameter as @Nullable and expand the
Javadoc to clarify the precedence of options.

Change-Id: I7aee800cdbf8243133a0d353ef79b97b67ce011e
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>

Bug: 485396
Change-Id: I82be09385c9b0bcc0054fea5a9cb9d178a41e278
Signed-off-by: Mickael Istria <mistria@redhat.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Add a new API method to set the recurse mode, and pass the mode into
the fetch command.

Extend the existing FetchCommandRecurseSubmodulesTest to also perform
the same tests for fetch. Rename the test class accordingly.

Change-Id: I12553af47774b4778f7011e1018bd575a7909bd0
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>

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>

Change-Id: I266b0c72d2827bcf2b86ddc6c1892d1a46c548eb
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>

Add a new method setTagOpt which sets the annotated tag behavior during
fetch. Pass the option to the fetch command.

No explicit tests are added; the fetch with tags functionality is already
covered by the tests of the fetch command.

Change-Id: I131e1f68d8fcced178d8fa48abf7ffab17f8e173
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>

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>

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>

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>

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>

- throw an API exception instead of an internal exception to allow
applications to handle this problem
- improve error message to give hints about possible root causes

Bug: 464660
Change-Id: Ib7d18bb2eeeac0fc218daea375b290ea5034bda1
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Change-Id: Ibf4c299f9d203c78cae79e61f88d4bea60ea2795
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Setting branch.<name>.rebase or pull.rebase to 'preserve' will preserve
merges during rebase. Also, pull.rebase is now consulted if there is no
branch-specific configuration.

Bug: 429664
Change-Id: I345fa295c7e774e0d0a8e6aba30fbfc3552e0084
Signed-off-by: Konrad Kügler <swamblumat-eclipsebugs@yahoo.de>

Signed-off-by: Laurent Goubet <laurent.goubet@obeo.fr>
Change-Id: I84e9d7b4b772b4ad7d3e7010aad78291d4d178fe

Bug: 431552
Change-Id: I469316f5645205016e1fa6b0fbd2ff3b509b14bc
Signed-off-by: Robin Stocker <robin@nibor.org>

Also imply remoteBranchName to match current branch name if it wasn't
configured in branch configuration.

Bug: 424812
Change-Id: Id852cedaefb2a537b6aa3c330b9861efad052f11
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

A few classes such as Constanrs are marked with @SuppressWarnings, as are
toString() methods with many liternal, but otherwise $NLS-n$ is used for
string containing text that should not be translated. A few literals may
fall into the gray zone, but mostly I've tried to only tag the obvious
ones.

Change-Id: I22e50a77e2bf9e0b842a66bdf674e8fa1692f590

Bug: 394501
Change-Id: I697e2fc82a46c03762111eb1de93e673a2643b4f
Signed-off-by: Chris Aniszczyk <zx@twitter.com>

On conflicts in rebase or cherry-pick, the conflict markers were like
this:

    <<<<<<< OURS
    a
    =======
    b
    >>>>>>> THEIRS

This is technically correct, but it could be better.

It's especially confusing during a rebase, where the meaning of
OURS/THEIRS is not obvious. The intuition is that "ours" is the commits
that "I" did before the rebase, but it's the other way around because of
the way rebase works. See various bug reports and stackoverflow
discussions.

With this change, in the case of a cherry-pick while on master, the
markers will be like this:

    <<<<<<< master
    a
    =======
    b
    >>>>>>> bad1dea Message of the commit I'm cherry-picking

In the case of a "git rebase master":

    <<<<<<< Upstream, based on master
    a
    =======
    b
    >>>>>>> b161dea Message of a commit I'm rebasing

It's not "master" because that would only be correct for the first
cherry-pick during a rebase, after that, it's master + already
cherry-picked commits.

And in the case of a "git pull --rebase":

    <<<<<<< Upstream, based on branch 'master' of git@example.org:repo
    a
    =======
    b
    >>>>>>> b161dea Message of a commit I'm rebasing

Bug: 336819
Change-Id: I1333a8dd170bb0077f491962013485efb6f2a926
Signed-off-by: Robin Stocker <robin@nibor.org>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

- Translate internal exceptions to corresponding API exception
- Do not catch GitAPI exceptions internally to an internal
exception. Just pass them to caller
- Mention thrown exceptions in javadoc

Change-Id: I9044cf86d2b0bcc8b63b7cc016e1bf0055a62053
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

All commands should throw a GitAPIException so new exceptions can be
added without breaking the builds of old code, i.e. anyone that calls
a Git API should catch GitAPIException and not just the currently known
exceptions.

Now the only checked exceptions on Git API calls are GitException and
subclasses of it. New checked exceptions that are subclasses of
GitException may be added without breaking the API.

Javadoc for GitAPIException is declared on GitCommand and
inherited to subclasses. JGitInternalException is not explicitly
documented anymore.

Unfortunately this change itself breaks the API. The intention is
that it shall be possible to add new checked subclasses of
GitAPIException without breaking the API.

Bug: 366914
EGit-Change-Id: I50380f13fc82c22d0036f47c7859cc3a77e767c5
Change-Id: I50380f13fc82c22d0036f47c7859cc3a77e767c5
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Change-Id: I763590a45d75f00a09097ab6f89581a3bbd3c797

Throw a NoHeadException when Repository.getFullBranch
returns null

Bug: 351543
Change-Id: I666cd5b67781508a293ae553c6fe5c080c8f4d99
Signed-off-by: Kevin Sawicki <kevin@github.com>

Refactored the three common transport configuration options:
credentials provider, timeout, and transport config callback
into a new TransportCommand base class which is now extended
by all commands that use a Transport object during execution.

Bug: 349188
Change-Id: I90c2c14fb4e3cc4712905158f9047153a0c235c2
Signed-off-by: Kevin Sawicki <kevin@github.com>
Signed-off-by: Chris Aniszczyk <zx@twitter.com>

Add a TransportConfigCallback parameter to JGit API commands, to allow
consumers of the JGit command API to perform custom Transport configuration
that would be otherwise difficult to anticipate & expose on the API command
builders.


My specific use-case is configuring additional properties on SshTransport
- I need to take over the SshSessionFactory used by the transport. Using
TransportConfigCallback I can simply do this (rather than reimplement the
API command classes):

public void configure(Transport tn) {
  if (tn instanceof SshTransport) {
    ((SshTransport) tn).setSshSessionFactory(factoryProvider.get());
  }
}

Adding an explicit setSshSessionFactory() method to the JGit command
classes would bloat the API. Also, creating the replacement
SshSessionFactory is unnecessary if the transport is not SSH, but the type
of the Transport is only known once the remote has been resolved and the
URI parsed - consequently it makes sense to perform this step in a
callback, where the transport instance can be inspected to determine if
it's of a relevant type.


A note about where this leaves the API - there are now 4 commands:

CloneCommand
PullCommand
FetchCommand
PushCommand

-that share 3 identical transport-related parameters:

timeout
credentialsProvider
transportConfigurator

I think there's potential for introducing an interface or val-object to
identify/encapsulate this repetition, which I'd be happy to do in a
subsequent commit.

Change-Id: I8983c3627cdd7d7b2aeb0b6a3dadee553378b951
Signed-off-by: Roberto Tyley <roberto.tyley@gmail.com>

Change-Id: Ie2dde43da491fa27b25a2ad8014866d77d484b24
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Add a test case for PullCommand for the successful merge case and test
that the short ref name is used.

Change-Id: I16cbbc88595f73e5512f984e67f93f87ee0fe242
Signed-off-by: Robin Stocker <robin@nibor.org>

A checked Exception is thrown instead.

The reason for throwing an Exception is that the state of the
repository is inconsistent in this case: There is a merge
configuration containing a non-existing local branch. Ideally the
deletion of a local branch should also delete the corresponding
merge configuration.

Bug: 337315
Change-Id: I8ed57d5aaed60aaab685fc11a8695e474e60215f
Signed-off-by: Stefan Lay <stefan.lay@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

A checked Exception is thrown instead. 

The reason for throwing an Exception is that the state of the
repository is inconsistent in this case: There is a merge
configuration containing a non-existing local branch. Ideally the
deletion of a local branch should also delete the corresponding
merge configuration.

Bug: 337315
Change-Id: I71e56ffb90e11e6e3c1bbd964ad63972d67990c0
Signed-off-by: Stefan Lay <stefan.lay@sap.com>

When pulling into a local branch that has no upstream configuration,
pull should try to used the default remote ("origin") instead of
throwing an Exception.

Bug: 336504
Change-Id: Ife75858e89ea79c0d6d88ba73877fe8400448e34
Signed-off-by: Mathias Kinzler <mathias.kinzler@sap.com>

After consulting with Christian Halstrick, it turned out that the
handling of rebase during pull was implemented incorrectly.

Change-Id: I40f03409e080cdfeceb21460150f5e02a016e7f4
Signed-off-by: Mathias Kinzler <mathias.kinzler@sap.com>

Bug: 335703
Change-Id: Id9713a4849c772e030fca23dd64b993264f28366
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>

Rebase must honor the upstream configuration

branch.<branchname>.rebase

Change-Id: Ic94f263d3f47b630ad75bd5412cb4741bb1109ca
Signed-off-by: Mathias Kinzler <mathias.kinzler@sap.com>

Each time getConfig() is called on FileRepository, it checks the
last modified time of both ~/.gitconfig and $GIT_DIR?config.  If
$GIT_DIR/config appears to have been modified, it is read back in
from disk and the current config is wiped out.

When mutating a configuration file, this may cause in-memory edits
to disappear.  To avoid that callers need to avoid calling getConfig
until after the configuration has been saved to disk.

Unfortunately the API is still horribly broken.  Configuration should
be modified only while a lock is held on the configuration file, very
similar to the way a ref is updated via its locking protocol.  But our
existing API is really broken for that so we'll have to defer cleaning
up the edit path for a future change.

Change-Id: I5888dd97bac20ddf60456c81ffc1eb8df04ef410
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

The field monitor is never null, it's a NullProgressMonitor when not
explicitly set.

Change-Id: I8ce703a32c28ce5c3455efeb7ed5f5c9a443cbef

When creating a local branch based on another local branch, the
upstream configuration contains "." as origin and the source branch
as "merge". The PullCommand should support this by skipping the
fetch step altogether and use the base branch to merge with.

Change-Id: I260a1771aeeffca5b0161d1494fd63c672ecc2a6
Signed-off-by: Mathias Kinzler <mathias.kinzler@sap.com>

This is the minimal implementation of a "Pull" command. It does not
have any parameters besides the generic progress monitor and timeout.
It works on the currently checked-out branch and assumes that the
configuration contains the keys "branch.<branch name>.remote" and
"branch.<branch name>.merge" to determine the remote configuration
for the fetch and the remote branch name for the merge.

Bug: 303404
Change-Id: I7fe09029996d0cfc09a7d8f097b5d6af1488fa93
Signed-off-by: Mathias Kinzler <mathias.kinzler@sap.com>
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>