Entries should only be written to the working tree managed by the
Repository. Simplify callers by passing only the entry and computing
the work tree location inside of the checkoutEntry method.
Change-Id: I574e41280d0407f1853fda12f4bd0d30f75d74e7
ResolveMerger: Use the ObjectReader to access objects
This is necessary to ensure objects accessed by the TreeWalk come from
the associated ObjectInserter when the merger is a RecursiveMerger
instance and a virtual common base was constructed but not flushed.
Change-Id: Iebe739d30fd868ebc4f61dbfb714673146a2c3ec
The base Merger class already has a single ObjectReader instance that
it handles releasing as necessary, so creating new readers is not
necessary.
Change-Id: I990ec43af7df448c7825fc1b10e62eadaa3e0c2a
Process most in-core merges without local temp files
Instead of always writing to disk use TemporaryBuffer.LocalFile to
store up to 10 MiB of merge result in RAM. Most source code will
fit into this limit, avoiding local disk IO for simple merges.
Larger files will automatically spool to a temporary file that
can be cleaned up in the finally, reducing the risk of leaving
them on disk and consuming space in /tmp.
Change-Id: Ieccbd9b354d4dd3d2bc1304857325ae7a9f34ec6
ResolveMerger: push result file creation into updateIndex()
The only caller of writeMergedFile is updateIndex, and the only
user of this path object is the code within the method. This is
a no-op change that opens the door to refactoring the way temp
files are handled for inCore merges.
Change-Id: I863a303194689a806b667e55eb958e1decf046c1
Fix API errors raised on ResolveMerger affecting API providers only
In change If45bc3d078b3d3de87b758e71d7379059d709603 a new parameter was
added to 3 protected methods of ResolveMerger. This breaks the code of
developers which have subclassed ResolveMerger. The API baseline check
in Eclipse reports this as API breakage.
Since this will break only providers but not consumers of the API this
should be allowed also in minor versions. According to OSGi semantic
versioning
http://www.osgi.org/wiki/uploads/Links/SemanticVersioning.pdf
breaking providers in a minor version update is ok.
Therefore silence these errors using API filter rules.
Bug: 440757
Change-Id: Icabbd0e1de7e877c66a5c4a2c8391473f992a1aa
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
RecursiveMerger should not fail on content-merge conflicts of parents
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
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>
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 fixes two cases:
- A folder without tracked content exist both in the workdir and merged
commit, as long as there names within that folder does not conflict.
- An empty folder structure exists with the same name as a file in the
merged commit.
Bug: 402834
Change-Id: I4c5b9f11313dd1665fcbdae2d0755fdb64deb3ef
Extend ResolveMerger with RecursiveMerger to merge two tips
that have up to 200 bases.
Bug: 380314
CQ: 6854
Change-Id: I6292bb7bda55c0242a448a94956f2d6a94fddbaa
Also-by: Christian Halstrick <christian.halstrick@sap.com>
Signed-off-by: Chris Aniszczyk <zx@twitter.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
A few classes such as Constanrs are marked with @SuppressWarnings, as are
toString() methods with many liternal, but otherwise $NLS-n$ is used for
string containing text that should not be translated. A few literals may
fall into the gray zone, but mostly I've tried to only tag the obvious
ones.
Change-Id: I22e50a77e2bf9e0b842a66bdf674e8fa1692f590
ResolveMerger throws a MissingObjectException when it encounters
a submodule conflict while merging. The reason is that it treats
the submodule link as a blob and tries to read its contents.
We solve the issue by detecting before content merge whether the
path to be merged is a submodule link, and skip the content
merge if it is.
Bug: 389238
Change-Id: I9a58dfc7716b28a21f5c04cf3a865091ae8dfe7e
Signed-off-by: Tommi Siivola <tommi.siivola@eficode.com>
Again teach ResolveMerger to create more correct DirCacheEntry's
Currently, after a merge/cherry-pick/rebase, all index entries are
smudged as the ResolveMerger never sets entry lengths and/or
modification times. This change teaches it to re-set them at least for
things it did not touch. The other entries are then repaired when the
index is persisted, or entries are checked out.
The first attempt to get this in was commit
3ea694c252 which has been reverted.
Since then some fixes to ResolveMerger and a few more tests have
been added which check situations where the index is not matching
HEAD before we merge.
Change-Id: I648fda30846615b3bf688c34274c6cf4bc857832
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Also-by: Markus Duft <markus.duft@salomon.at>
Teach ResolveMerger to create more correct DirCacheEntry's
Currently, after a merge/cherry-pick/rebase, all index entries are
smudged as the ResolveMerger never sets entry lengths and/or
modification times. This change teaches it to re-set them at least for
things it did not touch. The other entries are then repaired when the
index is persisted, or entries are checked out.
Change-Id: I0944f2017483d32043d0d09409b13055b5609a4b
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Fix order of deletion for files/dirs in ResolveMerger
Before, the paths to delete were stored in a HashMap, which doesn't have
a particular order. So when e.g. both the file "a/b" and the directory
"a" were to be deleted, it would sometimes try to delete "a" first. This
resulted in a failed path because File#delete() fails when a directory
isn't empty.
With this change, an ArrayList is used for storing the paths to delete.
The list contains the paths in a top-down order, as defined by the order
of processEntry. When the files are deleted, the list is iterated in
reverse, ensuring that all files of a directory are deleted before the
directory itself.
Bug: 354099
Change-Id: I6b2ce96b3932ca84ecdfbeab457ce823c95433fb
Signed-off-by: Robin Stocker <robin@nibor.org>
Don't return success on failing paths in ResolveMerger
ResolveMerger#mergeImpl() was only returning false (= failed) when there
were unmerged paths. In the case when there were only failing paths, it
returned true.
Because MergeCommand looks at the return value for determining if the
merge failed, it would fall into the successful case there, where it
should instead return a MergeResult with MergeStatus.FAILED.
This change adds a test case for this and makes the ResolveMerger return
false when there are failing paths.
This was discovered while working on fixing bug 354099 and is needed for
its test case.
Bug: 354099
Change-Id: I499f518f6289ef93e017db924b2aa857f2154707
Signed-off-by: Robin Stocker <robin@nibor.org>
The base class supplies an ObjectInserter to its implementations
by way of the getObjectInserter method. Tracking a second inserter
instance doesn't match with the expected behavior.
Change-Id: I78996bd06ef9028c8aa2e4e192ff647c43da847d
Add isModeDifferent method to WorkingTreeIterator
that compares mode with consideration of the
core.filemode setting in the config.
Bug: 379004
Change-Id: I07335300d787a69c3d1608242238991d5b5214ac
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Compare modes before comparing ids in ResolveMerger
Comparing ids can be more expensive so do the cheap
mode check first and short circuit the id comparison
when modes are non-equal
Change-Id: I671eda51c74a411cc27de9d6077cc76e816ebe2b
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>
Fix ResolveMerger not to add paths with FileMode 0
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>
Change Ia2ab4f8dc95020f2914ff01c2bf3b1bc62a9d45d added merge
support for when OURS or THEIRS was simultaneously deleted
and modified. That changeset however did not add create an
entry in the conflicts table so clients would see a CONFLICTING
result but getConflicts() would return null.
This change creates a MergeResult for the conflicting file.
Bug: 345684
Change-Id: I52acb81c1729b49c9fb3e7a477c6448d8e55c317
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
Implemented merge for parallel delete/modification
Duplicates cgit behaviour for merging the case where
OURS is deleted and THEIRS is modified as well as
OURS is modified and THEIRS id deleted.
Change-Id: Ia2ab4f8dc95020f2914ff01c2bf3b1bc62a9d45d
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
This change contains a simple renaming. Instead of using the
expression 'abnormal failure', we just treat this kind of situation
as 'failure'. This is specific enough as conflicts are already handled
separately.
Change-Id: I535acdc7d022543ed0f5ac6151b09a6985f4ef38
Signed-off-by: Philipp Thun <philipp.thun@sap.com>
Add paths causing abnormal merge failures (e.g. due to unstaged
changes) to the MergeResult returned by MergeCommand. This helps
callers to better handle (e.g. present) merge results.
Change-Id: Idb8cf04c5cecfb6a12cb880e16febfc3b9358564
Signed-off-by: Philipp Thun <philipp.thun@sap.com>
In case a file needs to be checked out (from THEIRS) during a merge
operation, it has to be checked if the worktree version of this file
is dirty. If this is true, merge shall fail.
Change-Id: I17c24845584700aad953c3d4f2bea77a0d665ec4
Signed-off-by: Philipp Thun <philipp.thun@sap.com>
1. Perform an explicit check for untracked files.
2. Extract 'dirty checks' into separate methods
3. Clean up comments.
4. Tests: also check contents of files not affected by merge.
Change-Id: Ieb089668834d0a395c9ab192c555538917dfdc47
Signed-off-by: Philipp Thun <philipp.thun@sap.com>
To improve runtime performance, caching the WorkingTreeOptions inside
of the Config object using the Config.SectionParser API allows
the WorkingTreeOptions to be accessed more efficiently whenever a
FileTreeIterator is constructed for the Repository.
Instead of passing the filemode handling option into isModified(),
the WorkingTreeIterator should always honor whatever setting has
been configured in this repository, as defined by its own copy of
the WorkingTreeOptions. This simplifies all of the callers as they
no longer need to lookup core.filemode on their own.
A few locations were changed from always using a hardcoded "true"
on the file mode to passing what is actually configured in the
repository. This is a behavior change, but corrects what should be
considered to be bugs as the core.filemode variable wasn't always
being used.
Change-Id: Idb176736fa0dc97af372f1d652a94ecc72fb457c
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Some method parameters in WorkingTreeIterator are never used. Remove
them. Especially the removal of the FS parameter in isModified()
simplifies upcoming performance optimizations.
Change-Id: I7c449589283a4a6b6e23f2586cd784febdca8bcd
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
Its confusing that a new TreeWalk() needs to have reset() invoked
on it before addTree(). This is a historical accident caused by
how TreeWalk was abused within ObjectWalk.
Drop the initial empty tree from the TreeWalk and thus remove a
number of pointless reset() operations from unit tests and some of
the internal JGit code.
Existing application code which is still calling reset() will simply
be incurring a few unnecessary field assignments, but they should
consider cleaning up their code in the future.
Change-Id: I434e94ffa43491019e7dff52ca420a4d2245f48b
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
java.io.File.delete() reports failure as an exceptional
return value false. Fix the code which silently ignored
this exceptional return value. Also remove some duplicate
deletion helper methods.
Change-Id: I80ed20ca1f07a2bc6e779957a4ad0c713789c5be
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
When in OURS and THEIRS a new file is created we want a conflict
when the two contents differ. If on two branches the same file
with the same content is created this should not be a conflict.
But: the current merge algorithm is throwing NPEs in this case.
Fix this by choosing an empty RawText as common base if the
base is empty.
Change-Id: I21cb23f852965b82fb82ccd66ec961c7edb3ac3d
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
The diff algorithm which is used by Merge, Cherry-Pick, Rebase
should be configurable. A new configuration parameter "diff.algorithm"
is introduced which currently accepts the values "myers" or
"histogram". Based on this parameter for example the ResolveMerger
will choose a diff algorithm. The reason for this is bug 331078.
This bug shows that JGit is more compatible with C Git when
histogram diff is in place. But since histogram diff is quite new we
need an easy way to fall back to Myers diff.
Bug: 331078
Change-Id: I2549c992e478d991c61c9508ad826d1a9e539ae3
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Signed-off-by: Philipp Thun <philipp.thun@sap.com>
Fix bug regarding handling of non-versioned files during merge
There was a bug introduced by commit 0e815fe. For non-versioned files
the merge algorithm detected an incoming deletion from THEIRS.
Consequently such files were deleted. That's a severe bug which was
fixed by more precisely detecting incoming deletions.
Change-Id: I4385d3c990db11d62e371a385dc8ee89841db84a
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Signed-off-by: Philipp Thun <philipp.thun@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Fixed ResolveMerger regarding handling of deletions
There was a bug in ResolveMerger which is one reason for
bug 328841. If a merge was failing because of conflicts
deletions where not handled correctly. Files which have
to be deleted (because there was a non-conflicting deletion
coming in from THEIRS) are not deleted. In the
non-conflicting case we also forgot to delete the file but
in this case we explicitly checkout in the end these files
get deleted during that checkout.
This is fixed by handling incoming deletions explicitly.
Bug: 328841
Change-Id: I7f4c94ab54138e1b2f3fcdf34fb803d68e209ad0
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Optional inCore parameter to Resolver/Strategy will
instruct it to perform all the operations in memory
and avoid modifying working folder even if there is one.
Change-Id: I5b873dead3682f79110f58d7806e43f50bcc5045
Shawn Pearce
Shawn Pearce
Dave Borowitz
Robin Stocker
Christian Halstrick
Laurent Goubet
Robin Rosenberg
Matthias Sohn
George C. Young
Tommi Siivola
Markus Duft
Tomasz Zarna
Kevin Sawicki
Bernard Leach
Philipp Thun
Dmitry Fink