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>
Robin Rosenberg