Previously when RecursiveMerger was trying to create a single virtual
common base for the merge it was failing when this lead to content-merge
conflicts. This is different from what native git is doing. When native
git's recursive merge algorithm creates a new common base it will merge
the multiple parents and simply take the merge result (potentially
including conflict markers) as common base. See my discussion with Shawn
here: http://www.spinics.net/lists/git/msg234959.html :
> - How should workingtree, index (stage1,2,3) look like if during
that
> merge of common ancestors a conflict occurs? Will I see in stage2
and
> stage3 really see content of X1 and X2?
Its done entirely in memory and never touches the working tree or
index. When a conflict exists in the X1-X2 merge the conflict is
preserved into the new virtual base.
There is still the possibility that the merge of parents lead to
conflicts. File/Folder conclicts, conflicts on filemodes. This commit
only fixes the situation for conflicts when merging content.
Bug: 438203
Change-Id: If45bc3d078b3d3de87b758e71d7379059d709603
During recursive merge jgit potentially has to merge multiple
common ancestors. If this fails because there are conflicts then
the exception thrown for that should have a message which states
this clearly. Previously a wrong message was given ("More than 200
merge bases ...")
Change-Id: Ia3c058d5575decdefd50390ed83b63668d31c1d1
Each time the longest common substring is found the diff algorithm
recurses to reprocess the regions before and after the common string.
Large files with many edits can trigger StackOverflowError as the
algorithm attempts to process a deeply split tree of regions. This
is especially prone to happen in servers where the Java stack size
may have been limited to 1M or even 256K.
To keep edits produced in order a queue is used to process edits
in a depth-first strategy.
Change-Id: Iae7260c6934efdffac7c7bee4d3633a8208924f7
When RecursiveMerger tried to determine a common base tree it was
recursively tried to merge multiple common bases. But these intermediate
merges which have just been done to determine a single common base for
the final merge already filled some important fields (toBeCheckedOut,
toBeDeleted, ...). These side effects of the intermediate merges led to
wrong results of the final merge. One symptom was that after a recursive
merge which should be succesful you could still see leftover files in
the worktree: files which existed in the (virtual) common base but which
don't exist anymore in the branches to be merged.
The solution is easy: Clear the appropriate fields after common base
determination and start the final merge with a clean state.
Change-Id: I644ea9e1cb15360f7901bc0483cdb9286308c226
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
As described in native gits file "git-read-tree.txt" git has in a
special mode when doing the "initial" checkout. "Initial" means that the
index is empty before the checkout. This was not handled correctly in
JGit and is fixed in this commit. Also see
https://github.com/git/git/blob/master/Documentation/git-read-tree.txt#L181
Change-Id: I9b9d1bd9ebf349cfca420c891c7b099a18d07ba4
Setting branch.<name>.rebase or pull.rebase to 'preserve' will preserve
merges during rebase. Also, pull.rebase is now consulted if there is no
branch-specific configuration.
Bug: 429664
Change-Id: I345fa295c7e774e0d0a8e6aba30fbfc3552e0084
Signed-off-by: Konrad Kügler <swamblumat-eclipsebugs@yahoo.de>
With --preserve-merges C Git re-does merges using the rewritten merge
parents, discarding the old merge commit. For the common use-case of
pull with rebase this is unfortunate, as it loses the merge conflict
resolution (and other fixes in the merge), which may have taken quite
some time to get right in the first place.
To overcome this we use a two-fold approach:
If any of the (non-first) merge parents of a merge were rewritten, we
also redo the merge, to include the (potential) new changes in those
commits.
If only the first parent was rewritten, i.e. we are merging a branch
that is otherwise unaffected by the rebase, we instead cherry-pick the
merge commit at hand. This is done with the --mainline 1 and --no-commit
options to apply the changes introduced by the merge. Then we set up an
appropriate MERGE_HEAD and commit the result, thus effectively forging a
merge.
Apart from the approach taken to rebase merge commits, this
implementation closely follows C Git. As a result, both Git
implementations can continue rebases of each other.
Preserving merges works for both interactive and non-interactive rebase,
but as in C Git it is easy do get undesired outcomes with interactive
rebase.
CommitCommand supports committing merges during rebase now.
Bug: 439421
Change-Id: I4cf69b9d4ec6109d130ab8e3f42fcbdac25a13b2
Signed-off-by: Konrad Kügler <swamblumat-eclipsebugs@yahoo.de>
Allows to pass for example a List<RevCommit>.
Change-Id: I5522707060d7d3e0d848ba579956dc62f8fa0234
Signed-off-by: Konrad Kügler <swamblumat-eclipsebugs@yahoo.de>
DiffFormatter now suports either side being null and the log program
will output the diff for the first commit.
Bug: 395791
Change-Id: I378957b57e9ad1f7195ba416f402178453f0ebd3
Making the methods static would gain little in performance,
make the code harder to change. Removing unncessary warnings
is more important.
Change-Id: If3e6aa9c1d92e58b4e7a8e246cf4aace237d7a7b
These settings were added by Eclipse simply by touching
the project settings. Adding these makes it simpler to see
what local changes have been made.
Change-Id: Iab0aa62530312eb0c78b03b5c6a632742bcc4978
{} is plain wrong and is not accepted by MessageFormat, the other risk
becoming wrong if another single quote is introduced in the future and
sets a bad example.
Bug: 438261
Change-Id: I2948ca90c10f6ec2574f7f2b9be0a72821ea4daf
Connecting to an SshSession may fail due to different reasons. Jsch for
example often throws an com.jcraft.jsch.JschException: verify: false.[1]
The issue is still not fixed in JSch 0.1.51.
In such a case it is worth retrying to connect. The number of connection
attempts can be configured using ssh_config parameter
"ConnectionAttempts" [2].
Don't retry if the user canceled authentication.
[1] http://sourceforge.net/p/jsch/bugs/58/
[2] http://linux.die.net/man/5/ssh_config
Bug: 437656
Change-Id: I6dd2a3786b7d3f15f5a46821d8edac987a57e381
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The current behavior of passing a TreeFilter to RevWalk has limited
usefulness, since the RevFilter derived from the TreeFilter is always
ANDed together with any other RevFilters. It is also tied fairly
tightly to the parent rewriting mechanism.
Make TreeRevFilter a generic RevFilter that matches modified paths
against any TreeFilter. This allows for more complex logic like
(modified this path OR authored by this person).
Leave the rewrite flag logic in this class, since it's closely tied to
the parent comparison code, but hidden behind a protected constructor.
Change-Id: Ia72ef591a99415e6f340c5f64583a49c91f1b82f
Sometimes an input stream is more useful than the filename of the xml manifest.
Change-Id: Icb09ac751b3d8d7eb14427ad1aac8cee0c371c5f
Signed-off-by: Yuxuan 'fishy' Wang <fishywang@google.com>
DeltaTask$Block.partitionTask was doing an infinite loop if number of
threads was greater than the totalWeight. The weightPerThread was 0
which was causing the infinite loop. Set the weightPerThread to a
minimal value of one.
Bug: 420915
Change-Id: Ia8e3ad956d53d8193937b7fa1bc19aafde9767ff
Signed-off-by: Hugo Arès <hugo.ares@ericsson.com>
Originally, blame's walk to find a scapegoat to blame for a file
walking backward from a commit used the test
treeWalk.getFileMode(0).getObjectType() != OBJ_BLOB
to throw out gitlink (submodule) entries. Later, 52500d3264 (blame:
Micro optimize blob lookup in tree, 2014-04-17) changed that test to
(treeWalk.getRawMode(0) & TYPE_FILE) != TYPE_FILE
These checks are not the same, though: the older test accepts files
and symlinks, while the newer one accepts files, symlinks, and gitlink
(submodule) entries. This is particularly broken in the submodule
case --- trying to parse the referred-to commit as a blob produces
caught an exception: GET /gerrit/+blame/master/plugins/reviewnotes HTTP/1.1
org.eclipse.jgit.errors.MissingObjectException: Missing blob 61702414c046dd6b811c9137b765f9db422f83db
Stick to just (possibly executable) files instead. Symlinks are not
line-oriented data so blame on a symlink is not likely to be useful.
A quick grep for '& TYPE_' doesn't find any other instances of this
bug.
Change-Id: Iebcc91f1bee3c91adda51dccd6372e8302bf23fe
Signed-off-by: Jonathan Nieder <jrn@google.com>
TranslationBundle#load() used to load resource bundles through
ResourceBundle#getBundle() without explicitly specifying a class loader.
In this case, the class laoder of the calling class (TranslationBundle
here) is used. This approach fails in runtime environments like OSGi
where there are multiple class loaders.
This change enables loading resource bundles in multi class loaders
environments. The fix is to pass the class loader of the
TranslationBundle-derived class to ResourceBundle#getBundle().
Bug: 436232
Change-Id: I39db61e012dc93ebf388a71bf6088a3310a22bac
Signed-off-by: Rüdiger Herrmann <ruediger.herrmann@gmx.de>
When update the manifest against a bare repository, RepoCommand will replace
every existing content from the repository with contents populated from the
manifest. Added note for that and a unit test to make sure this behavior.
Change-Id: I1d5960e84bca5aa2a4e86f424d2ddd4197894cdc
Signed-off-by: Yuxuan 'fishy' Wang <fishywang@google.com>
0b5441a8 introduced an enum for authentication types and changed the
case of digest and basic authentication type names to all uppercase.
This broke digest authentication at least when using Gerrit as the git
server.
According to RFC2617 [1] "Basic" and "Digest" is the literal to be used
in authentication headers and not "BASIC" [1] and "DIGEST" [2].
According to RFC4559 "Negotiate" [3] is used for SPNEGO based
authentication.
[1] http://tools.ietf.org/html/rfc2617#page-5
[2] http://tools.ietf.org/html/rfc2617#page-8
[3] http://tools.ietf.org/html/rfc4559#page-3
Bug: 435866
Change-Id: I6173aff9352d7def225cafe2d73e5176ad40dff0
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The call() function of LsRemoteCommand returns Collection<Ref>, while its
internal is using Map<String, Ref> all the time. Sometimes the map is much more
useful to the caller so add a callAsMap() function to keep the API
compatibility.
Change-Id: Icb96b71277d5e2de59872aa777352dedc048c4e3
Signed-off-by: Yuxuan 'fishy' Wang <fishywang@google.com>
Unstashed changes are saved in a commit which is added as an additional
parent to the stash commit.
This behaviour is fully compatible with C Git stashing of untracked
files.
Bug: 434411
Change-Id: I2af784deb0c2320bb57bc4fd472a8daad8674e7d
Signed-off-by: Andreas Hermann <a.v.hermann@gmail.com>
If a client passes a multiline message as argument to ReflogWriter.log()
the Reflog gets corrupted and cannot be parsed. ReflogWriter.log() is
invoked implicitly from various commands such as StashCreate, Rebase and
many more. However the message is not always filtered for line feeds.
Such an example is the StashCreateOperation of EGit which passes
unchecked user input as commit message. If a multiline comment is pasted
to the stash create dialog, the reflog gets corrupted.
ReflogWriter now replaces line endings in log message with spaces.
Bug: 435509
Change-Id: I3010cc902e13bee4d7b6696dfd11ab51062739d3
Signed-off-by: Andreas Hermann <a.v.hermann@gmail.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The aim of this change is to place all commits of a branch on the same
lane and commits of other (side) branches on different lanes.
The algorithm treats first parents of a commit specially by placing them
on the same lane as the commit itself. When a commit is the first parent
of multiple children it could be placed on any of these children's
lanes. In this case it is placed on the longest child lane, as this is
usually the lane of the branch the commit actually was made on.
Other (non-first) parents are placed on new lanes. This creates a layout
that should make it easier to see branches and merges and follow linear
branch histories.
This differs from the previous approach, which sometimes plotted the
commits of a side branch on the same lane as the base branch commits and
further commits on the base branch appeared on a different lane.
This made the base branch appear as if it was the side branch and
the side branch appears to be the base branch.
In addition to lane assignment, also the plotting code changed to start
drawing a branch lane from the commit where it forks out. Previously it
started only when the first commit on the branch appeared.
Active lanes are continued with every commit that is processed.
Previously lanes were only continued when the next commit on the lane
was encountered. This could produce (temporarily) dangling commits if
the next commit on the lane was not processed yet.
CQ: 8299
Bug: 419359
Bug: 434945
Change-Id: Ibe547aa24b5948ae264f7d0f56a492a4ef335608
Signed-off-by: Konrad Kügler <swamblumat-eclipsebugs@yahoo.de>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Christian Halstrick
Shawn Pearce
Yuxuan 'fishy' Wang
Konrad Kügler
Robin Rosenberg
Robin Stocker
Matthias Sohn
Stefan Lay
Dave Borowitz
Anton Bannykh
Hugo Arès
Jonathan Nieder
Rüdiger Herrmann
Dani Megert
Andreas Hermann