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
"Invalid tree aa6f10291050a00de83b4630783030b9e3b969ec:duplicate entry names"
is hard to read. A space after the object name and before the message
makes the message more readable.
Change-Id: I96406100dbef8e4bc8fe2047d102681194dc8847
The exception is caught in Main and System.exit() is called.
Bug: 413522
Change-Id: Ibe68f7104d4fd55b832000a7840c07a169e7dd58
Signed-off-by: Guillaume Nodet <gnodet@gmail.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Leverage these streams to remove calls to System.in and System.err
Bug: 413522
Change-Id: I8396f3e273c93e23861e8bcfb2ab8182fb09220d
Signed-off-by: Guillaume Nodet <gnodet@gmail.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Make jgit.java6 and jgit.java7 activation based on ranges so modules in
jgit.java6 are enabled for Java 1.6+ and modules in jgit.java7 are
enabled for Java 1.7+. This enables full compiles on Java 8 and also
removes the need to list org.eclipse.jgit.console in both profiles.
Change-Id: Iabfcff18737ff435ba8d5e8efc7a581abc9a46ce
Signed-off-by: Alexander Kurtakov <akurtako@redhat.com>
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
* stable-3.3:
Prepare 3.3.2-SNAPSHOT builds
JGit v3.3.1.201403241930-r
Retry to call credentials provider if http authentication failed
Ensure that ssh authentication is retried only in JGit
[findBugs] Ensure streams are closed in a finally block
Update com.jcraft.jsch to 0.1.50 also in pom dependencies
Change-Id: I45b48a3f2dc8c7708e9518645d72bc5645002836
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Under certain circumstances isMergedInto() returned
false even though base is reachable from the tip.
This will hinder pushes and receives by falsely
detecting "non fast forward" merges.
o---o---o---o---o
/ \
/ o---o---A---o---M
/ /
---2---1-
if M (tip) was compared to 1 (base), the method
isMergedInto() could still return false, since
two mergeBases will be detected and the return
statement will only look at one of them:
return next() == base;
In most cases this would pass, but if "A" is
a commit with an old timestamp, the Generator
would walk down to "2" before completing the
walk pass "A" and first finding the other
merge base "1". In this case, the first call to
next() returns 2, which compared to base evaluates
as false.
This is fixed by iterating merge bases and
returning true if base is found among them.
Change-Id: If2ee1f4270f5ea4bee73ecb0e9c933f8234818da
Signed-off-by: Gustaf Lundh <gustaf.lundh@sonymobile.com>
Signed-off-by: Sven Selberg <sven.selberg@sonymobile.com>
If the user provided wrong credentials or credentials changed we
shouldn't give up immediately but retry to get valid credentials from
the credentials provider. Reset the credentials provider if
authentication failed to avoid it reuses wrong credentials in
case it stored them in a persistent store.
Bug: 338048
Bug: 342592
Bug: 427735
Change-Id: Ibd62ef3da17be6454991c43f524c8bbc7ca3c37e
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
JGit wants to control retries during ssh authentication. But JSch by
default already retries 6 times. Hence disable retries in JSch. Without
this the credentials provider isn't reset if e.g. wrong credentials are
specified.
Bug: 430210
Change-Id: I6fa726a14a84b06411e7010608c7a1e2bfb8bfe8
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>
Copying flags through a graph with deep side branches can cause
StackOverflowError. The recursive step to visit the 2nd parent of
a merge commit can overflow the stack if these are themselves very
deep histories with many branches.
Rewrite the loop to iterate up to 500 recursive steps deep before
unwinding the stack and running the remaining parts of the graph
using a dynamically allocated FIFORevQueue.
This approach still allows simple graphs that mostly merge short
lived topic branches into master to copy flags with no dynamic
memory allocation, relying only on temporary stack extensions.
Larger more complex graphs only pay the allocation penalities
if copying has to extend outwards "very far" in the graph, which
is unlikely for many coloring based algorithms.
Change-Id: I1882e6832c916e27dd5f6b7602d9caf66fb39c84
Verifying 100 new objects are fully connected to the existing DAG
is usually very cheap. Checking the entire Linux kernel history is
fully connected when pushing it to a new repository can take 30-60
seconds. Display a progress counter during this time so the client
knows the server is still working.
Change-Id: Iababe3ee1d35cb82f2bef2f12da7a2ecd03282b0
* 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
fsck.allowLeadingZeroFileMode may be set true to permit pushing
broken trees with leading '0' in the file mode.
fsck.safeForWindows may be set true to require new trees to have
only file names that are safe on the Windows platform.
fsck.safeForMacOS may be set true to require new trees to have
only file names that do not cause collisions or confusion on the
Mac OS platform.
Change-Id: I1a225c1b3cd13c0d1a0d43fffe79355c501f49b7
git-core configures fsck during fetch using these two variables.
JGit use of fsck in fetch predates the usage in git-core and had
reused receive.fsckobjects, which does not match behavior.
Change-Id: Ie4d5f082258c4b2928c7ecc3780c6363fa587f34
ReceivePack should configure itself with receive.fsckObjects,
and if not defined, transfer.fsckObjects. This is the order
used by git-core.
Change-Id: I41f243633dacb606dbcc3132972f63bbaba174d1
PackParser permits supplying a specific ObjectChecker instance.
Allow this to be passed through ReceivePack, giving the caller
more flexibility to configure the implementation.
Change-Id: I9440dd25588008626222f33bfd697f57c05b439e
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
Start pulling out the path segment checking. This will be used
later to support DirCacheCheckout verification of paths, after
folding that logic into this location.
Change-Id: I66eaee5c988eb7d425fb7a708ef6f5419ab77348
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
Catching Exception and rethrowing as Error when the Java7 factory was
not available threw an unexpected error to the caller, but then
confused things by still setting the factory to the default Java
5 version. A second call to FS.detect(Boolean) would succeed.
Do not throw to the caller. Instead always default to the Java5
factory if the Java7 one is not loading.
Change-Id: I6e9edb257b404d213ff08c44560fdb1672a5c80b
Konrad Kügler
Robin Rosenberg
Sven Selberg
Shawn Pearce
Matthias Sohn
Guillaume Nodet
Alexander Kurtakov
Stefan Lay
Christian Halstrick
Dave Borowitz
Gustaf Lundh
Rüdiger Herrmann