Remove it from
* package private functions.
* try blocks
* for loops
this was done with the following python script:
$ cat f.py
import sys
import re
import os
def replaceFinal(m):
return m.group(1) + "(" + m.group(2).replace('final ', '') + ")"
methodDecl = re.compile(r"^([\t ]*[a-zA-Z_ ]+)\(([^)]*)\)")
def subst(fn):
input = open(fn)
os.rename(fn, fn + "~")
dest = open(fn, 'w')
for l in input:
l = methodDecl.sub(replaceFinal, l)
dest.write(l)
dest.close()
for root, dirs, files in os.walk(".", topdown=False):
for f in files:
if not f.endswith('.java'):
continue
full = os.path.join(root, f)
print full
subst(full)
Change-Id: If533a75a417594fc893e7c669d2c1f0f6caeb7ca
Signed-off-by: Han-Wen Nienhuys <hanwen@google.com>
CloneCommand: Suppress resource warning about Repository
Repository is not opened in try-with-resource because it is wrapped
in a Git instance which should be closed by the caller. On exeptions
during fetch, it is explicitly closed in the catch blocks.
Suppress the warning with an explanatory comment.
Change-Id: Ib32c74ce39bb810077ab84db33002bdde806f3b6
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
Open auto-closeable resources in try-with-resource
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>
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>
CloneCommand: Refactor listing of files in deleteChildren
File.listFiles() returns null if the given File does not represent a
directory, so we can just test for null instead of making a separate
call to FS.DETECTED.isDirectory()
This also avoids a false-positive error from SpotBugs which claims
that there is a potential null-pointer exception on dereferencing the
result of Files.listFiles().
Change-Id: I18e09e391011db997470f5a09d8e38bb604c0213
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
The other methods in this class follow the builder pattern, and
return 'this', allowing multiple method calls to be chained in a
single statement.
Update the setCallback method to do the same.
Change-Id: I0366d28bf66ba47f08ee7eee636d613c9fe079f5
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
CloneCommand.call() has three stages: preparation, then the actual
clone (init/fetch), and finally maybe checking out the working
directory.
Restructure such that if we fail or are cancelled during the actual
clone (middle phase), we do clean up the disk again. This prevents
leaving behind a partial clone in an inconsistent state: either we
have a fully successfully built clone, or nothing at all.
Bug: 516303
Change-Id: I9b18c60f8f99816d42a3deb7d4a33a9f22eeb709
Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
Add the --recurse-submodules option on the command, which causes
submodules to also be initialized and updated.
Add a callback interface on CloneCommand and SubmoduleUpdateCommand to
them to provide progress feedback for clone operations.
Change-Id: I41b1668bc0d0bdfa46a9a89882c9657ea3063fc1
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Enable and fix warnings about redundant specification of type arguments
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' 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>
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>
[findBugs] Prevent potential NPE in CloneCommand.init()
File.listFiles() returns null if the File is not a directory, improve
validation of directory and gitDir to fix this.
Change-Id: I763d08835faf96a0beb8e706992df0908526bd2c
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Null-annotated Ref class and fixed related compiler errors
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>
Treat CloneCommand.setBranch(null) as setBranch("HEAD")
This method is documented to take a branch name (not a possibly null
string). The only way a caller could have set null without either
re-setting to a sane value afterward or producing NullPointerException
was to also call setNoCheckout(true), in which case there would have
been no reason to set the branch in the first place.
Make setBranch(null) request the default behavior (remote's default
branch) instead, imitating C git's clone --no-branch.
Change-Id: I960e7046b8d5b5bc75c7f3688f3a075d3a951b00
Signed-off-by: Jonathan Nieder <jrn@google.com>
Treat CloneCommand.setRemote(null) as setRemote("origin")
A non-bare clone command with null remote produces a
NullPointerException when trying to produce a refspec to fetch against.
In a bare repository, a null remote name is accepted by mistake,
producing a configuration with items like 'remote.url' instead of
'remote.<remote>.url'. This was never meant to work.
Instead, let's make setRemote(null) undo any previous setRemote calls
and re-set the remote name to DEFAULT_REMOTE, imitating C git clone's
--no-origin option.
While we're here, add some tests for setRemote working normally.
Change-Id: I76f502da5e677df501d3ef387e7f61f42a7ca238
Signed-off-by: Jonathan Nieder <jrn@google.com>
call() throws InvalidRemoteException if uri == null, so there should
never be reason to leave the URI set to null. Document this.
Change-Id: I7f2cdbe8042d99cf8a3c1a8c4c2dcb58c5b8c305
Signed-off-by: Jonathan Nieder <jrn@google.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>
Allow explicit configuration of git directory in CloneCommand
This feature is needed to support the new submodule layout where the
.git folder of the submodules is under .git/modules/<submodule>.
Change-Id: If5f13426cfd09b7677e23478e9700c8c25a6dae5
Handle short branch/tag name for setBranch in CloneCommand
Before, it was not clear from the documentation what kind of branch name
was accepted. Users specifying "branch" (instead of "refs/heads/branch")
got no error message and ended up with a repository without HEAD and no
checkout.
With this, CloneCommand now tries "$branch", then "refs/heads/$branch"
and then "refs/tags/$branch". C Git only does the last two, but for
compatibility we should still allow "refs/heads/branch".
Bug: 390994
Change-Id: I4be13144f2a21a6583e0942f0c7c40da32f2247a
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
CloneCommand has been creating fetch refspecs like this on bare clones:
[remote "origin"]
url = ssh://example.com/my-repo.git
fetch = +refs/heads/*:refs/heads//*
As you can see, the destination ref pattern has a superfluous slash.
It looks like this behaviour has always been the case for CloneCommand,
at least since cc2197ed when code catering to bare-clone fetch refspecs
was added. That was released with JGit v1.0 almost 2 years ago, so
there will probably be some bare repos in the wild which will have been
cloned with JGit and have these corrupted refspecs.
The effect of the corrupted fetch refspec is quite interesting. Up to
and including JGit 2.0, the corrupt refspec was tolerated and fetches
would work as intended with no indication to the user that anything was
amiss. With JGit 2.1, a change was introduced which made JGit less
tolerant, and fetches now attempt to update the non-existing ref
"refs/heads//master". No exception is raised, but the real ref -
"refs/heads/master" - is not updated.
This behaviour was noticed by a user of Agit (which does bare clones by
default and recently updated from JGit v2.0 to v2.2), reported here:
https://github.com/rtyley/agit/issues/92
If you run C-Git fetch on a bare-repo cloned by JGit, it flat-out
rejects the refspec (checked against v1.7.10.4):
fatal: Invalid refspec '+refs/heads/*:refs/heads//*'
Incidentally, C-Git does not create an explicit fetch refspec at all
when performing a bare clone - the full remote config generated by C-Git
looks like this:
[remote "origin"]
url = ssh://example.com/my-repo.git
Using JGit on such a repository works fine, so omitting the fetch
refspec entirely is also an option.
Change-Id: I14b0d359dc69b8908f68e02cea7a756ac34bf881
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
Whenever a call to JGit returns a Repository the caller should make sure
to call close() on it if he doesn't need it anymore. Since instances of
Repository contain e.g. open FileOutputStreams (for pack files)
forgetting to close the repository can lead to resource leaks.
This was the reason why dozens of the JUnit tests failed on Windows
with "Can't delete file ...." errors.
In LocalDiskRepositoryTestCase.tearDown() we tried to delete the
repositories we used during tests which failed because we had open
FileOutputStreams.
Not only the obvious cases during Clone or Init operations returned
Repositories, but also the new SubModule API created repository
instances. In some places we even forgot to close submodule repositories
in our internal coding.
To see the effects of this fix run the JGit JUnit tests under Windows.
On other platforms it's harder to see because either the leaking
resources don't lead to failing JUnit tests (on Unix you can delete
files with open FileOutputStreams) or the java gc runs differently and
cleans up the resources earlier.
Change-Id: I6d4f637b0d4af20ff4d501db091548696373a58a
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
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>
Git API does not declare GitAPIException call() and related cleanups
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>
Iterate over all successfully cloned submodules recursively
and continue initializing and updating until no more are found.
Bug: 375426
Change-Id: Ifb99e41e2deb0c369442bca3c0f5f072dd006816
Always checkout master when it matches the advertised HEAD
This parallels the CGit behavior of always using refs/heads/master
when it matches the remote advertised HEAD commit.
Change-Id: I5a5cd1516b58d116e334056aba1ef7990697ec30
Don't iterate over advertised refs when HEAD is null
Moves the check from inside the loop to outside the loop
and returns immediately if the HEAD advertisded ref is null
Change-Id: I539da6cafb4f73610b8e00259e32bd4d57f4f4cc
Support a configured credentials provider in LsRemoteCommand
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>
Enable full Transport configuration for JGit API commands
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>
The previous comment stated that the value set was used
to keep track of the branch in the remote repository
which was incorrect.
Updated the method comment to match the format used
for the PushCommand.setRemote and FetchCommand.setRemote
methods.
Change-Id: I11b81eb3125958af29247b485da56fd88c3bfdf5
Signed-off-by: Kevin Sawicki <kevin@github.com>
Cloning should fail when destination directory exists and is not empty
When trying to clone into a folder that already contains a cloned
repository native git will fail with a message "fatal: destination path
'folder' already exists and is not an empty directory.". Now JGit will
also fail in this situation throwing a JGitInternalException.
The test case was provided by Tomasz Zarna.
Bug: 347852
Change-Id: If9e9919a5f92d13cf038dc470c21ee5967322dac
Also-by: Tomasz Zarna <Tomasz.Zarna@pl.ibm.com>
Signed-off-by: Adrian Goerler <adrian.goerler@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Fix CloneCommand not to fetch into remote tracking branches when bare
When cloning into a bare repository we should not create remote
tracking branches (e.g refs/remotes/origin/testX). Branches of the
remote repository should but fetched into into branches of the same
name (e.g refs/heads/testX). Also add the noCheckout option which
would prevent checkout after fetch.
Change-Id: I5d4cc0389f3f30c53aa0065f38119af2a1430909
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
The timeout is also used in the FetchCommand called by the
CloneCommand.
The possibility to provide a list of branches to fetch initially is a
feature offered by EGit. To implement it here is a prerequisite for
EGit to be able to use the CloneCommand.
Change-Id: I21453de22e9ca61919a7c3386fcc526024742f5f
Signed-off-by: Stefan Lay <stefan.lay@sap.com>
When no branch was specified in the clone command, HEAD pointed to a
commit after clone. Now the clone command tries to find a branch which
points to the same commit and checks out this branch.
Bug: 339354
Change-Id: Ie3844465329f213dee4a8868dbf434ac3ce23a08
Signed-off-by: Stefan Lay <stefan.lay@sap.com>
If the clone command clones into a bare repository it should not try
to checkout HEAD in the end. For bare repos checkout is not possible.
Change-Id: I359719d421b93c9d2e962e3c0eccc2b59235c3d1
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Han-Wen Nienhuys
David Pursehouse
Markus Duft
Marc Strapetz
Matthias Sohn
Joan Goyeau
Thomas Wolf
Andrey Loskutov
Jonathan Nieder
Christian Halstrick
Robin Stocker
Robin Rosenberg
Roberto Tyley
Kevin Sawicki
Stefan Lay
Adrian Goerler