Adds support for Negotiate(SPNEGO) HTTP authentication method. This method
is set to have a higher priority as Digest HTTP authentication method.
Bug: 428836
Change-Id: Ib181096d39f538df1dd7d3f36516843777bf12ae
Signed-off-by: Laurent Goujon <lgoujon@twitter.com>
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
By specifying a mainline parent, a merge is cherry picked as if this
parent was its only parent. If no mainline parent is given, cherry
picking merges is not allowed, as before.
Change-Id: I391cb73bf8f49e2df61428c17b40fae8c86a8b76
Signed-off-by: Konrad Kügler <swamblumat-eclipsebugs@yahoo.de>
Adds further tests where the working tree is dirty (differs from
index) and where we have staged but uncommitted changes.
Fixed the test case 9 for file/directory conflicts.
Bug: 428819
Change-Id: Ie44a288b052abe936ebb74272d0fefef3b218a7a
Signed-off-by: Axel Richard <axel.richard@obeo.fr>
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Previously, it was only possible to archive the entire repository.
This patch introduces the ability to select specific files and
directories to archive.
Archiving the entire repository remains the default behaviour.
org.eclipse.jgit.api.ArchiveCommand: Adding setPaths(String... paths)
method.
Change-Id: Iedcd40fbfd71238b0088174bbe2717fae196e047
Signed-off-by: Shaul Zorea <shaulzorea@gmail.com>
* changes:
Do not rewrite parents in RevWalkTextBuiltins
RevWalk: Allow disabling parent rewriting
RevWalkTextBuiltin: Add -n to limit number of commits returned
Previously, setting any TreeFilter on a RevWalk triggered parent
rewriting, which in the current StartGenerator implementation ends up
buffering the entire commit history in memory. Aside from causing poor
performance on large histories, this does not match the default
behavior of `git rev-list`, which does not rewrite parent SHAs unless
asked to via --parents/--children.
Add a new method setRewriteParents() to RevWalk to disable this
behavior. Continue rewriting parents by default to maintain backwards
compatibility.
Change-Id: I1f38e05526071c75ca58095e312663de5e6f334d
When blaming a merge commit with "Ignore whitespace changes" enabled,
don't discard blame candidates for other parents when we encounter a
parent that only has whitespace changes compared to the merge result.
The algorithm early prepares parents for blaming, removing the
appropriate blame regions from the list of regions still to blame. Only
at the end, the prepared blame candidates are submitted for blaming.
When looking at a non-first parent which only differs in whitespace to
the merge result, it submitted that parent, but only to blame it for the
(usually few) lines not already prepared to blame on other parents. Due
to an early return the blame candidates for the previous parents were
forgotten, leaving many lines unannotated.
bug: 433024
Change-Id: I43c9caf2078b92b05e652dbed2192568907bf199
Signed-off-by: Konrad Kügler <swamblumat-eclipsebugs@yahoo.de>
When JGit uses bitmaps (which is the case after a gc), the push command
doesn't go through the code where MissingObjectExceptions are caught
for remote objects not found locally.
Fixed by removing earlier non-locally-found remote objects.
This was seen withing gerrit, see:
https://code.google.com/p/gerrit/issues/detail?id=2025
Bug: 426044
Change-Id: Ieda718a0530e3680036edfa0963ab88fdd1362c0
Signed-off-by: Jean-Jacques Lafay <jeanjacques.lafay@gmail.com>
Signed-off-by: Doug Kelly <dougk.ff7@gmail.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Instead of requiring the caller to know how to list remote
names or parse remote branch names, add a few utilities for
that.
Change-Id: Ib6b2403532f4abbce594a03c0b9da49d30b19f70
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
* changes:
Commit changes generated during repo command
Added implementation of copyfile rule.
Added groups support to repo subcommand.
Added the command line of jgit repo.
Implemented first part of the repo sub-command.
Streaming packed deltas is so slow that it never feasibly completes
(it will take hours for it to stream a few hundred megabytes on
relatively fast systems with a large amount of storage). This
was indicated as a "failed experiment" by Shawn in the following
mailing list post:
http://dev.eclipse.org/mhonarc/lists/jgit-dev/msg01674.html
Change-Id: Idc12f59e37b122f13856d7b533a5af9d8867a8a5
Signed-off-by: Doug Kelly <dougk.ff7@gmail.com>
Currently the repo sub-command only "works", but the submodules will have .git
directories themselves, and lacks group support.
Change-Id: I88a6ee07109187c6c9bfd92a044775fcfb5befa6
Signed-off-by: Yuxuan 'fishy' Wang <fishywang@google.com>
Problem:
The BlameGenerator used the RevFlag SEEN to mark commits it had
already looked at (but not necessarily processed), to prevent
processing a commit multiple times. If a commit is a conflicting
merge that contains lines of the merge base, that have been deleted
in its first parent, either these lines or the lines untouched
since the merge base would not be blamed properly.
This happens for example if a file is modified on a main branch in an
earlier commit M and on a side branch in a later commit S. For this
example, M deletes some lines relative to the common base commit B,
and S modifies a subset of these lines, leaving some other of these
lines untouched.
Then side is merged into main, creating a conflict for these
lines. The merge resolution shall carry over some unmodified lines
from B that would otherwise be deleted by M. The route to blame
these lines is via S to B. They can't be blamed via M, as they
don't exist there anymore.
Q
|\
| \
| S
| |
M |
| /
|/
B
Blaming the merged file first blames via S, because that is the
most recent commit. Doing so, it also looks at B to blame the
unmodified lines of B carried over by S into the merge result. In the
course of this, B is submitted for later processing and marked SEEN.
Later M is blamed. It notices that its parent commit B has been
SEEN and aborts processing for M. B is blamed after that, but only
for the lines that survived via S.
As a result, only the lines contributed by S or by B via S are
blamed. All the other lines that were unchanges by both M and S,
which should have been blamed to B via M, are not blamed.
Solution:
Don't abort processing when encountering a SEEN commit. Rather add the
new region list of lines to be blamed to those of the already SEEN and
enqueued commit's region list. This way when the B commit of the
above example is processed, it will blame both the lines of M and S,
yielding a complete blame result.
Bug: 374382
Change-Id: I369059597608022948009ea7708cc8190f05a8d3
Signed-off-by: Konrad Kügler <swamblumat-eclipsebugs@yahoo.de>
Signed-off-by: Shawn Pearce <spearce@spearce.org>
Change-Id: Id9a641dd67c4182bb3a0dc83a6864fee43e7653f
Signed-off-by: Gustaf Lundh <gustaf.lundh@sonymobile.com>
Signed-off-by: Sven Selberg <sven.selberg@sonymobile.com>
There are certain ref names which native git can be create only on
non-windows systems (e.g. "refs/tags/>"). On Windows systems we can't
persist this refs because the ref names are not valid file names. Our
tests in ValidRefNameTest assumed that these are valid refs on all
systems. This broke the tests on Windows.
Change-Id: Ic53c396c88b84cbdf579a636953f7519952270c0
This would be a problem for any OS where Java lets the subscond
part through to the File API. The fix is to force the timetamp
of the index rather than trusting it to just happen to be right.
Bug: 430765
Change-Id: Id6b3ba003f58427a3ffaacd224649e2d6c93566b
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
When safeForMacOS is enabled the checker verifies a name does not
match against another name in the same tree after normalization to
NFC. The check was incorrect and failed when the first name was put
in, rejecting simple trees containing only one file like "F".
Add a test for this simple tree to verify it is accepted.
Fix the test for NFC normalization to actually normalize
and have a collision.
Change-Id: I39e7d71150948872bff6cd2b06bf8dae52aa3c33
When working on a non-bare repository with a detached HEAD jgit's GC was
packing the ref named "HEAD" into the packed-refs file and deleted the
loose ref (the file .git/HEAD!). This made the repo unusable for native
git. This is fixed by telling jgit to only pack refs starting from
"refs/"
Change-Id: I50018aa006f18b244d2cae2ff78b5ffe1b821d63
Previously, calling addAnnotatedTags() did not modify any state when
there were no annotated tags in the repository. This caused the code
to assume no addFoo() methods had been called, and fell back to the
default of adding refs/*. Instead, use null to indicate neither
addRefs() nor addAnnotatedTags() was called.
Add a test for this behavior.
Change-Id: I9926e5ac17e1a983cd399798993031c72bd79c2c
When more than one lane is drawn, some commits are vertically misaligned
(off by two pixels). This change fixes the alignment.
Bug: 426047
Change-Id: Icbe7ce9f5a6b281b2aaab66e4d76dfc1010b2fb5
Signed-off-by: Konrad Kügler <swamblumat-eclipsebugs@yahoo.de>
Signed-off-by: Rüdiger Herrmann <ruediger.herrmann@gmx.de>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* changes:
Allow configuration of receive pack's ObjectChecker through fsck.*
Correct fetch to use fetch.fsckObjects and transfer.fsckObjects
Default receive.fsckObjects to transfer.fsckObjects
Allow ReceivePack callers to configure their own ObjectChecker
Check for duplicate names after folding case in ObjectChecker
Change DirCacheCheckout to verify path using ObjectChecker
Reject mixed case .git on Mac OS in ObjectChecker
Reject special Windows device names in ObjectChecker
Allow an ObjectChecker to reject special characters for Windows
Reject '.git' as a tree name in ObjectChecker
Extract path segment check function in ObjectChecker
Permit ObjectChecker to optionally accept leading '0' in trees
Mac OS X and Windows filesystems are generally case insensitive and
will fold 'a' and 'A' to the same directory entry. If the checker is
enforcing safe semantics for these platforms, track all names and
look for duplicates after folding case and normalizing to NFC.
Change-Id: I170b6f649a72d6ef322b7254943d4c604a8d25b9
Reuse the generic logic in ObjectChecker to examine paths.
This required extracting the scanner loop to check for bad
characters within the path name segment.
Change-Id: I02e964d114fb544a0c1657790d5367c3a2b09dff
Most Mac OS X systems use a case insensitive HFS+ volume. Like
Windows ".git" and ".GIT" are the same path and can confuse a Git
program into expecting a repository where one does not exist.
Change-Id: Iec6ce9e6c2872f8b0850cc6aec023fa0fcb05ae4
If Windows rejection is enabled reject special device names like
NUL and PRN, including NUL.txt. This prevents a tree that might
be used on a Windows client from referencing a confusing name.
Change-Id: Ic700ea8fa68724509e0357d4b758a41178c4d70c
Repositories that are frequently checked out on Windows platforms
may need to ensure trees do not contain strange names that cause
problems on those systems. Follow the MSDN guidelines and refuse
to accept a tree containing a special character, or names that end
with " " (space) or "." (dot).
Since Windows filesystems are usually case insensitive, also reject
mixed case versions of the reserved ".git" name.
Change-Id: Ic3042444b1e162c6d01b88c7e6ea39b2a73c4eca
Using .git as a name in a tree is invalid for most Git repositories.
This can confuse clients into thinking there is a submodule or another
repository deeper in the tree, which is incorrect.
Change-Id: I90a1eaf25d45e91557f3f548b69cdcd8f7cddce1
The leading '0' is a broken mode that although incorrect in the
Git canonical tree format was created by a couple of libraries
frequently used on a popular Git hosting site. Some projects have
these modes stuck in their ancient history and cannot easily
repair the damage without a full history rewrite. Optionally permit
ObjectChecker to ignore them.
Bug: 307291
Change-Id: Ib921dfd77ce757e89280d1c00328a88430daef35
One specific test was executed when running tests from inside eclipse
(e.g. by using one of our checked in launch configurations). But when
running tests from maven this test was not executed. Maven (the surefire
plugin) looks for Tests only in java files which are named like
"Test*.java", "*Test.java" or "*TestCase.java". Tests in files named
"*Tests.java" are not found.
Change-Id: I62a80fd6e6fda8bd76fdf3f3f2b8cbc56460fb2c
Blaming with core.autocrlf set to 'true' - even for freshly checked out
files - showed all lines as being locally modified. For autocrlf = true
the line breaks of the local file will be converted to LF for blaming.
This results in useful diffs and therefor in the desired blame
annotations.
For autocrlf = input no conversion takes place to cope with CRLF line
breaks in the repository, in addition to the usual LF. For autocrlf =
true CRLF line breaks in the repo can't be supported without additional
effort. In that case the whole local file will be blamed as being
locally modified.
Change-Id: If020dcca54d16b2fb79210a070b8480aec82e58e
Signed-off-by: Konrad Kügler <swamblumat-eclipsebugs@yahoo.de>
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
* stable-3.3:
Update scripts to deploy jgit on Maven central
Prepare 3.3.1-SNAPSHOT builds
JGit v3.3.0.201403021825-r
Fix merge/cherry-picking in CRLF mode
Expose the received pack size in ReceivePack
Revert "Add getPackFile to ReceivePack to make PostReceiveHook more usable"
Avoid an NPE after 7b01a53692
Add a launcher for Java 7 tests
Remove obsolete getRepositoryMethod from WorkingTreeIterator
Fix NPE when WorkingTreeIterator does not have a repository set
Add getPackFile to ReceivePack to make PostReceiveHook more usable
Possibility to limit the max pack size on receive-pack
Package httpclient and httpcore in o.e.j.http.apache.feature
Change-Id: I814a150980854bbaabd767f97b062d247af6cb50
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This fixes a case where we have CRLF in the repo but
LF in the worktree and are in autocrlf mode.
Change-Id: I0388270c1cf0fd22dfd513bcaa404eb97268d39d
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
When git-core renames or copies a file and the mode differs the
header shows the mode change first, then the rename or copy data:
diff --git a/COPYING b/LICENSE
old mode 100644
new mode 100755
similarity index 92%
rename from COPYING
rename to LICENSE
index d645695..54863be
--- a/COPYING
+++ b/LICENSE
@@ -56,20 +56,6 @@
JGit relies on this ordering inside of FileHeader. Parsing "new file
mode NNN" after "copy from/to" or "rename from/to" resets the change
type to be ADD, losing the COPIED or RENAMED status and old path.
This fixes a 4 year old bug in Gerrit Code Review that prevents
opening a file for review if the file was copied from another file,
modified in this change, and the mode was updated (e.g. execute
bit was added).
Change-Id: If4c9ecd61ef0ca8e3e1ea857301f7b5c948efb96
[ms: added test case]
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Previously all HTTP communication was done with the help of
java.net.HttpUrlConnection. In order to make JGit usable in environments
where the direct usage of such connections is not allowed but where the
environment provides other means to get network connections an
abstraction for connections is introduced. The idea is that new
implementations of this interface will be introduced which will not use
java.net.HttpUrlConnection but use e.g.
org.apache.client.http.HttpClient to provide network connections.
One example: certain cloud infrastructures don't allow that components
in the cloud communicate directly with HttpUrlConnection. Instead they
provide services where a component can ask for a connection (given a
symbolic name for the destination) and where the infrastructure returns
a preconfigured org.apache.http.client.HttpClient. In order to allow
JGit to be running in such environments we need the abstraction
introduced in this commit.
Change-Id: I3b06629f90a118bd284e55bb3f6465fe7d10463d
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
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>
Read options that control squashing, whether or not to commit the merge
and regarding fast forwarding from the configuration and use them if no
explicit values for these options have been provided to MergeCommand.
Change-Id: Ifdaed4b5e4adc142657c03c8e78b709a99eeddbd
Signed-off-by: Konrad Kügler <swamblumat-eclipsebugs@yahoo.de>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
When the caller specifies to JGit in advance that a ref-update is a
non-fast-forward update, and that those are permitted, we should never
need to call the potentially expensive isMergedInto() check. Re-checking
that the older commit is /not/ reachable from the newer is superfluous.
http://dev.eclipse.org/mhonarc/lists/jgit-dev/msg02258.html
Change-Id: I4bbf593de4dcea6b6f082881c1a33cb3a6a7fb89
Signed-off-by: Roberto Tyley <roberto.tyley@gmail.com>
Formerly the 4-arg constructor did not do this, which was unfortunate
as that constructor's the only way for an external user of JGit to set
the /type/ of the ref-update - which you might want to do to indicate
that the update is expected to be a UPDATE_NONFASTFORWARD, and thus does
not require expensive isMergedInto() calculations:
http://dev.eclipse.org/mhonarc/lists/jgit-dev/msg02258.html
Change-Id: I84c5e4927131e105bed93e31a62da6367c78de32
Signed-off-by: Roberto Tyley <roberto.tyley@gmail.com>
On Windows the length reported by FileAttributes is the size
of the target file (a bug, I guess) rather than the link,
so we read the linke and look at the length of the link instead.
Bug: 353771
Change-Id: I834b06d0447f84379612b8c9190fa77093617595
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The "cut off" optimization causes it to not include branches that
contain the specified commit but happen to share commits with a branch
that does not contain the commit.
An example:
-B foo
\
-A---C master
findBranchesReachableFrom for commit A with both branches as input may
not return master (depending on the order of the input). The reason is
that A is not contained in foo, and therefore the old code would put B
in the cutOff set. When then walking the master commits and B is
checked, it is found in the cutOff set and the walk is aborted, causing
master not to be returned even though it should.
Bug: 425674
Change-Id: I2c0c406ce5fcc9a03538b483473af930d4895d30
Signed-off-by: Robin Stocker <robin@nibor.org>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The change includes comparing symbolic links between disk and index,
adding symbolic links to the index, creating/modifying links on
checkout. The behavior is controlled by the core.symlinks setting, just
as C Git does. When a new repository is created core.symlinks will be
set depending on the capabilities of the operating system and Java
runtime.
If core.symlinks is set to true, the assumption is that symlinks are
supported, which may result in runtime errors if this turns out not to
be the case.
Measuring the cost of jgit status on a repository with ~70000 files,
of which ~30000 are tracked reveals a penalty of about 10% for using
the Java7 (really NIO2) support module.
Bug: 354367
Change-Id: I12f0fdd9d26212324a586896ef7eb1f6ff89c39c
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This version does not attempt to unsmudge, unlike the first attempt
in Idafad150553df14827eccfde2e3b95760e16a8b6.
Bug: 372834
Change-Id: I9300e735cb16d6208e1df963abb1ff69f688155d
Also-by: Robin Stocker <robin@nibor.org>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Signed-off-by: Robin Stocker <robin@nibor.org>
The folder .git/rebase-merge was not removed in this case. The
repository was then still in rebase state, but neither abort nor
continue worked.
Bug: 425742
Change-Id: I43cea6c9e5f3cef9d6b15643722fddecb40632d9
To correspond to the behavior of "git branch", also return HEAD in case
it is detached.
Bug: 425678
Change-Id: Ie615731434d70b99bd18c7a02e832c0a2c3ceef3
Signed-off-by: Robin Stocker <robin@nibor.org>
Package was renamed, so I had to update the imports. Also, I verified
bitmap serialization was still compatible.
Change-Id: I161ad3875b963b56001beab477ef8d072accee4f
* stable-3.2:
Canonicalize worktree path in BaseRepositoryBuilder if set via config
Add missing @since tags for new public methods in Config
Don't use API exception in RebaseTodoLine
Fix aborting rebase with detached head
Add recursive variant of Config.getNames() methods
Prepare post 3.2.0-m3 builds
JGit v3.2.0.201311130903-m3
Change-Id: Iad6e284e0fe2c7950f156372b334e47ebd82f3f7
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This came up while testing the proposed buck build for jgit. With buck
we can introduce smaller modules to allow for more concurrency during
build and to better control inner structure of jgit. Trying to put the
porcelain API into a different module than lower level implementation
classes failed since RebaseTodoLine used a porcelain API exception
causing a dependency cycle on the proposed modules. Using an exception
defined on the same abstraction level fixes this problem.
Change-Id: I26a5353e1a8fc23e67d8ce61309bd964f7665bcb
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
These methods allow to find all configuration entry names for a given
section or section/subsection searching recursively through all base
configurations of the given configuration.
These methods are needed to calculate the names for the effective
configuration of a git repository which combines the configuration entry
names found in the repository, global and system configuration files
Bug: 396659
Change-Id: Ie3731b5e877f8686aadad3f1a46b2e583ad3b7c6
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This feature was introduced in native git with version 1.8.4.
Bug: 422951
Change-Id: I42f194174d64d7ada6631e2156c2a7bf93b5e91c
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Instead of just a generic "Invalid path: $path", add a reason for the
cases where it's not obvious what the problem is (e.g. "aux" being
reserved on Windows).
Bug: 413915
Change-Id: Ia6436bd2560e4f049c92d9aac907cb87348605e0
Signed-off-by: Robin Stocker <robin@nibor.org>
The matcher has to be reset before using it, as was already done in the
other cases.
Bug: 423039
Change-Id: I87abaa7ad7f0aac8651db6e88d41427cacb4d776
Also-by: Ondrej Vrabec <ovrabec@netbeans.org>
Signed-off-by: Robin Stocker <robin@nibor.org>
When there are conflicts with a recursive merge, the conflicting paths
are stored in unmergedPaths (field in ResolveMerger). Later, when the
MergeResult is constructed in MergeCommand, getBaseCommit is called,
which computes the merge base a second time.
In case of RecursiveMerger, getBaseCommit merges the multiple merge
bases into one. It does this not by creating a new ResolveMerger but
instead calling mergeTrees. The problem with mergeTrees is that at the
end, it checks if unmergedPaths is non-empty and returns false in that
case.
Because unmergedPaths was already non-empty because of the real merge,
it thinks that there were conflicts when computing the merge base again,
when there really were none.
This can be fixed by storing the base commit when computing it and then
returning that instead of computing it a second time.
Note that another possible fix would be to just use a new ResolveMerger
for merging the merge bases instead. This would also remove the need to
remember the old value of dircache, inCore and workingTreeIterator (see
RecursiveMerger#getBaseCommit).
Bug: 419641
Change-Id: Ib2ebf4e177498c22a9098aa225e3cfcf16bbd958
Signed-off-by: Robin Stocker <robin@nibor.org>
With this change jgit checks for uncommitted changes before a rebase is
started. This is also done by native git. One reason is that an abort
would override such changes. The check is skipped for a non-interactive
rebase when it will result in a fast-forward. In this case there can be
only checkout conflicts but no merge conflicts, so there cannot be an
abort which overrides uncommitted changes.
Bug: 422352
Change-Id: I1e0b59b2a4d80a686b67a6729e441924362b1236
Signed-off-by: Stefan Lay <stefan.lay@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
JGit was not handling certain file/folder conflicts during a checkout
correctly. This was reported by Axel Richard in
http://dev.eclipse.org/mhonarc/lists/jgit-dev/msg02358.html.
This commit fixes this problem.
Still JGit behaves intentionally different than native git.
If HEAD contains a tree, and workingtree, Index and Merge contain a file
with same content ... then JGit allows a conflict free checkout of
Merge. Native git always complains that it doesn't want to overwrite
local changes. But there is no need to update the working tree because
Index and Merge are already equal.
A shell script which shows how native git behaves can be found here.
https://gist.github.com/chalstrick/7694959#file-gistfile1-sh
Change-Id: Ifd6a68974d61cd4fa23bc575f3a40773db66cafc
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Applying a stash on another commit failed because the merge base for the
cherry-pick of the stashed index state was not corectly set.
Bug: 422684
Change-Id: I9355352b2b9a7abefa3248ca3c17a9301177d0d6
Signed-off-by: Stefan Lay <stefan.lay@sap.com>
Separate some sections of the GC tests into different test classes.
Individual classes permits running in parallel under Buck, reducing
test latency if there are sufficient CPUs available.
Change-Id: I5eb177f78efd4aa8ac857d0d8b1a1fd81ca07790
Instead of making a new PackFile from a resource, lookup
the existing PackFile that was already created by the base
class SampleDataRepositoryTestCase.
Change-Id: Ib5da18c832ae0cb29703706b99e99503f5cc819d
This class requires resources which are private to another
bundle. Move the class next to its resources, removing an
odd cross bundle dependency.
Change-Id: I30d5568b09ea5fb3bd3bb60b602f149c0867f49a
Otherwise switching to another locale yields wrong results when parsing
date strings in GitDateParser. Since the MockSystemReader explicitly
uses english locale the tests need to specify the locale to be used when
parsing date strings.
Bug: 420772
Change-Id: I313ef6b1e9ef3bfb43d929ce34712ebd21f2cd9c
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Empty lines of discarded commit messages were added to the commit
message because they were not commented out properly.
Bug: 422246
Change-Id: I263e8a6b30a3392d8b4f09c0695505068a0a485d
Signed-off-by: Stefan Lay <stefan.lay@sap.com>
The API in org.eclipse.jgit.api does allow to open repositories but it
did not allow to close them. This commit fixes this and allows
API users to close a repository without having to use lower-level
classes.
Bug: 420502
Change-Id: I866225cc8534ae5916113fa24eb1c7513fd4472e
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
If during an garbage collection old packfiles are deleted it could
happen that on certain platforms the index file can be deleted but the
packfile can't be deleted (because someone locked the file). This led
to repositories with packfiles without corresponding index files. Those
zombie-packfiles potentially consume a lot of space on disk and it is
never tried to delete them again. Try to avoid this situation by
deleting packfiles first and don't try to delete the other files if we
can't delete the packfile. This gives us the chance to delete the
packfile during next GC.
This commit only improves the situation - there is still the chance for
orphan files during packfile deletion. We don't have an atomic delete
of multiple files .
Change-Id: I0a19ae630186f07d0cc7fe9df246fa1cedeca8f6
Result of c.containsAll(c) is always true for any collection c.
Change-Id: I853cbb44bdc03e2b54229bb9c36ae42e02dcc4d9
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
If a commit was marked for edit, reword, squash or fixup, but the
interactive rebase stopped because of a conflict, the step was not done
after conflict resolution. This is done now.
Change-Id: If8e7ccc50469165744f2b8a53d180f9ba0f72330
Signed-off-by: Stefan Lay <stefan.lay@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
When the last step was an edit step, rebase interactive did not finish
after continuing the rebase. Instead, it returned with the status
FAST_FORWARD.
Change-Id: Ib19857474ac089dfeaae665ad5e95c66c21099b0
Matthias Sohn