In many cases applications want to handle TransportException hence
expose it as an API exception.
Change-Id: I64b885ecfb1a35bd93c89026c6298d1820ba69d0
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This will allow recovery from a LockFailedException where
the file associated with an exception is passed to FileUtils.unlock
to attempt an unlock on the file so the operation can be retried
Change-Id: I580166d386126bfb54a318a65253070a6e325936
API commands either throw GitAPIException or JGitInternalException.
Also add missing javadoc and reduce nesting of catch blocks.
Change-Id: I9a3b302e1b3f373ee11a977a0e3d6213bfbd3cdf
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Signed-off-by: Kevin Sawicki <kevin@github.com>
Currently files in a repository marked as executable will have
that mode unset when modified and committed on systems that
do not support detection of this mode since the working tree
iterator will never report this mode for any entries.
This change updates WorkingTreeIterator to be able
to determine the target file mode to be used for the index
through consideration of the configured WorkingTreeOptions.
Bug: 364956
Change-Id: Iae496baa011b8a59d9329ec73615482b03d34a5a
This allows all the settings of a TransportCommand to be
configured on the clone commands that are run by submodule
add/update
Change-Id: I93bfe5a91d430200de8c7f1e32a60cb990aa58ea
Adds the following commands:
- Add
- Init
- Status
- Sync
- Update
This also updates AddCommand so that file patterns added that
are submodules can be staged in the index.
Change-Id: Ie5112aa26430e5a2a3acd65a7b0e1d76067dc545
Signed-off-by: Kevin Sawicki <kevin@github.com>
Signed-off-by: Chris Aniszczyk <zx@twitter.com>
* stable-1.2:
JGit v1.2.0.201112221803-r
Expose unmerged paths when revert fails
Enforce the use of Java5 API:s only (with a few exceptions)
Change-Id: Ib18d41a65e68cc47fb63114fcce27a16820d0692
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The places where ResolveMerger was doing content merges have been
refactored. The goal was to have one single method where content merge
was done and to factor out other topics (updating the index, updating
the working tree) into own methods. This was done to allow adding
pluggable content mergers in change
I7817e2123d254f3eeb315b47a61d2c55bd202c12
Change-Id: I8529697b197372a284bcd5ab2c9ba1adb925a520
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
This will allows calling classes to handle lock failures
without checking against the message and will also provide
access to the file that could not be locked.
Change-Id: I95bc59e1330a7af71ae3b0485c4516299193f504
Revision strings such as 'master@{0}' can now be resolved
by Repository.resolve by reading the reflog for the ref and
returning the commit for the entry number specified.
This still throws an exception for cases not supported
such as 'master@{yesterday}'.
Change-Id: I6162777d6510e083565a77cac4545cda5a9aefb3
* stable-1.2:
Add API checking using clirr
Fix MergeCommandTest to pass if File.executable is not supported
Fix ResolveMerger not to add paths with FileMode 0
Change-Id: I86e7194a40acd6dfa3d433f1d17c01bdf5bb0d9c
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This only works with Eclipse 3.6 and newer and requires installation
of new package. Documentation is not very good, but there is a blog
about it here:
http://eclipseandjazz.blogspot.com/2011/10/of-invalid-references-to-system.html
API checking is especially useful on OS X where Java5 is not readily
available.
Change-Id: I3c0ad460874a21c073f5ac047146cbf5d31992b4
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
In order to generate API reports run: mvn clirr:clirr
The reports are generated to the folder
target/site/clirr-report.html under the respective
project.
In order to check API compatibility and fail the build
on incompatible changes run: mvn clirr:check
For now we compare the API against the latest release
1.1.0.201109151100-r.
Bug: 336849
Change-Id: I21baaf3a6883c5b4db263f712705cc7b8ab6d888
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Signed-off-by: Kevin Sawicki <kevin@github.com>
This also updates DiffFormatter to not write path lines
for entries that have the same object id
Bug: 361570
Change-Id: I830a78e2babf472503630a7aa020ebfd5c7e69c6
Once a pack has been committed with commitPack(), we know that the pack
list has changed but we don't re-scan the underlying storage.
Change-Id: Ia7b35df4442a5f5dfe7e817edcc77b44b5410d08
All setters for JGit API commands return the command instance, follow
the builder pattern.
Change-Id: Id2bbc3f1300bb179887c4d2d6dd72925bde55f24
Signed-off-by: Kevin Sawicki <kevin@github.com>
When ResolveMerger finds a path where it has to do a content merge it
will try the content merge and if that succeeds it'll add the newly
produced content to the index. For the FileMode of this new index entry
it blindly copies the FileMode it finds for that path in the common base
tree. If by chance the common base tree does not contain this path it'll
try to add FileMode 0 (MISSING) to the index.
One could argue that this can't happen: how can the ResolveMerger
successfully (with no conflicts) merge two contents if there is no
common base? This was due to another bug in ResolveMerger. It failed to
find out that for two files which differ only in the FileMode (e.g. 644
vs. 755) it should not try a content merge.
Change-Id: I7a00fe1a6c610679be475cab8a3f8aa4c08811a1
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Matthias Sohn
Robin Rosenberg
Kevin Sawicki
Tomasz Zarna
Stefan Lay
Christian Halstrick
Shawn Pearce
Dave Borowitz