File system time stamps and System.currentTimeMillis() may not
necessarily be running on the same clock so add some slack.
Bug: 396662
Change-Id: I25204d9e3181e15368da2902447518c6ce205017
My guess is that the higher resolution of timestamps provided by Java on
Windows causes this test to occasionally fail.
Bug: 396662
Change-Id: Ia10d76e95fe6156c7ad05972619160e461606805
In case of a conflict during cherry-pick or revert the commit message
was amended after the footer. This made the footer invalid. Many users
do not understand that they have to edit the commit message in order to
make it valid again.
Change-Id: I7e7fae125129e2a0d8950510550acda766531835
Bug: 367416
Additionally expose methods to find the first footer line and to find
the position of the ChangeId footer in the commit message in order to
enable reuse of these methods introduced for the fix.
Change-Id: I87ecca009ca3bff1ca0de3c436ebd95736bf5a10
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Previously the result of an application would have been \r\r\n in the
case of windows line endings, as RawText does not touch the \r, and
ApplyCommand adds "\r\n" if this is the ending of the first line in the
target file. Only always adding \n should be ok, since \r\n would be the
result if the file and the patch include windows line endings.
Also add according test.
Change-Id: Ibd4c4948d81bd1c511ecf5fd6c906444930d236e
Previously, the Dfs GC excluded objects from packs by passing a
previously written index to the PackWriter. Reading back a file on
Dfs is slow. Instead, allow the PackWriter to expose the objects
included in a pack and forward that to invocations of excludeObjects() .
Change-Id: I377cb4ab07f62cf790505e1eeb0b2efe81897c79
FastForwardMode is represented by different strings depending on context
it is set or get from. E.g. FastForwardMode.FF_ONLY for
branch.<name>.mergeoptions is "--ff-only" but for merge.ff it is "only".
Change-Id: I39ae93578e4783de80ebf4af29ae23b3936eec47
PackConstants previously contained string values for the pack and pack
index extension. Change PackConstant to be PackExt, a typed wrapper
around the string pack file extension.
Change-Id: I86ac4db6da8f33aa42d6f37cfcc119e819444318
The primary purpose of the filter is to detect an index change that
could possibly lead to a change in what files are visible in the staging
view and decorations. Besides what TreeFilter.ANY_DIFF does for trees in
general, this filter also looks at the assume-valid (CE_VALID) flag to
see whether changes should be ignored or not.
Change-Id: I13e9ed4ae62dc3851204fba598239edce07ca977
The method is used in only one location (DfsPackFile). Furthermore,
PackIndex already does an explicit computation of the size in
DfsPackFile. Simplify the DfsPackDescription by removing the method
and do the calculation similar to PackIndex.
Change-Id: I1391fdaaf7c2c3226d96ada1ae8647bcdff4794e
Previously the size getters and setters had explicit methods for index
and pack. Update the api to be based on the file extension. This will
make it possible to support other extensions in the future, such as
the forthcoming bitmap extensions.
Change-Id: Iab9d4abe0af65b2fc71ad71ef1db0feb6b3b5c58
If multiple threads attempted to insert loose objects into the same new
fan-out directory, the creation of that directory was subject to a race
condition that could lead to an unnecessary IOException being thrown -
because an inserter could not 'create' a directory that had just been
generated by a different thread. All we require is that the directory
does indeed *exist*, so not being able to _create_ it is not actually a
fatal problem. Setting 'skipExisting' to 'true' on the call to mkdir()
fixes the issue.
I found this issue as a real world occurrence while working on The BFG
Repo Cleaner (https://github.com/rtyley/bfg-repo-cleaner), a tool which
concurrently performs a lot of object creation.
In order to demonstrate the problem here I've added a small test case
which reliably reproduces the issue on the few different hardware
systems I've tried. The error thrown when the race-condition arises is
this:
java.io.IOException: Creating directory /home/roberto/repo.git/objects/e6 failed
at org.eclipse.jgit.util.FileUtils.mkdir(FileUtils.java:182)
at org.eclipse.jgit.storage.file.ObjectDirectory.insertUnpackedObject(ObjectDirectory.java:590)
at org.eclipse.jgit.storage.file.ObjectDirectoryInserter.insertOneObject(ObjectDirectoryInserter.java:113)
at org.eclipse.jgit.storage.file.ObjectDirectoryInserter.insert(ObjectDirectoryInserter.java:91)
at org.eclipse.jgit.lib.ObjectInserter.insert(ObjectInserter.java:329)
Change-Id: I88eac49bc600c56ba9ad290e6133d8a7113125ab
This converts a checkout conflict exception into a RebaseResult /
MergeResult containing the conflicting paths, which enables EGit (or
others) to handle the situation in a user-friendly way
Change-Id: I48d9bdcc1e98095576513a54a225a42409f301f3
This is necessary because some versions of JGit containing
the flawed c98abc9c05 were
used in the wild and wrote bad configuration files. We now
must accept this value in addition to the preferred case.
Change-Id: I3ed5451735658df6381532499130e5186805024a
Previously, the FileObjDatabase required both the pack file path and
index file path to be passed to openPack(). A future change to add
a bitmap index will add a .bitmap file parallel to the pack file
(similar to the .idx file). Update the PackFile to support
automatically loading pack index extensions based on the pack file
path.
Change-Id: Ifc8fc3e57f4afa177ba5a88df87334dbfa799f01
Previously, the DfsObjDatabase had a hardcoded getPackFile() and
getPackIndex() methods which opens a .pack and .idx file, respectively.
A future change to add a bitmap index will need to be stored in a
parallel .bitmap file. Update the DfsObjDatabase to support opening and
writing of files for any pack extension.
Change-Id: I7c403b501e242096a2d435f6865d6025a9f86108
Once we start talking about parents of tags, we are in the commit
graph, so treat all objects from this point as commits. This fixes
spurious IncorrectObjectTypeExceptions on resolving expressions like
tag^^.
Change-Id: I29ece1fdb49c9c5b9ca415efcd1876bc72e97120
It stopped working when we moved to the Eclipse foundation's Gerrit
server since it doesn't use the Gerrit internal user store but LDAP.
Instead, since 2.0, we use the Eclipse foundation's automatic IP log
generator [1] to generate IP logs for releasing jgit and egit.
[1] http://www.eclipse.org/projects/ip_log_selector.php
Change-Id: I98dc65efb62909bc0258e6c680df0c93a57e9677
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
FastForwardMode should be represented by different enums depending on
context it is set or get from. E.g. FastForwardMode.FF_ONLY for
branch.<name>.mergeoptions is "--ff-only" but for merge.ff it is "only".
Change-Id: I3ecc16d48e715b81320b73ffae4caf3558f965f2
This requires that we internally sort all paths so content of
directories follow the directory immediately.
Bug: 397185
Change-Id: I3e9735c7bdd99437929da8f9c9d4960a1273054b
When piping output to another program, the other pipe may exit
before we are done. An example is "jgit log|head". The result is
that errno get set to EPIPE. Unfortunately Java does not have
specific exception for this so we have to look at the exception
message and hope that the number of variants are small.
The detection here seem to work on Windows, Linux and OS X and it
seems the message is usually not localized.
Change-Id: Id6968ea7a53ae27ba5496303f1a479e41e41fdcc
The org.eclipse.jgit.orbit.feature introduced recently in order to
install 3rd party Orbit dependencies is a too coarse grained approach
and has the effect to install some dependencies only needed for
org.eclipse.jgit.pgm when installing org.eclipse.jgit.feature.
Hence include the required 3rd party bundles into the respective jgit
features directly in order to avoid this problem.
Bug: 397356
Change-Id: I3a4a07de42808e787515a6865875d9513542d3f8
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This logic is similar to what we do on Windows, but in this case it's
Java that truncates the timestamps, not Git.
Bug: 395410
Change-Id: Ie55dcb9fa583f5c3dd10d7a1b582e5b04b45858d
This reverts commit 75eb6a147f.
Applications that want a PathFilter to abort the walk early should be
using PathFilterGroup. When a PathFilterGroup is created with exactly
one path its implementation is the same that 75eb6 tried to perform,
but has been long documented as having the behavior of breaking a
higher level OR filter graph node.
Change-Id: I6c85d75c474784471c32e866eef3402b9f193c08
Cherry-pick has been fixed, but even though revert does
basically the same thing, the fixes were not carried over here.
- Recognize the revert-states, analogous to the cherry picking states
- Make reset handle a revert-in-progress
- Update REVERT_HEAD and MERGE_MSG when revert fails due to conflicts
- Clear revert state on commit and reset
- Format the message similarily to how cherry-pick does. This is
not exactly how C Git does it.
The interface is still not the same as for cherry-picking.
Change-Id: I8ea956fcbc9526d62a2365360feea23a9280eba3
Signed-off-by: Chris Aniszczyk <zx@twitter.com>
After the current path of the TreeWalk is no longer a prefix of the
PathFilter's path, there can be no more matching entries, but TreeWalk
will happily keep walking the rest of a (potentially very large and
recursive) tree unless StopWalkException is thrown. So, throw
StopWalkException from PathFilter.include() at the earliest
opportunity.
Change-Id: If6c4f395a3d5ed5b71bf68de23be9f2b0620e7f1
The maxMemory for a DeltaWindow can be optionally disabled when it is
less than or equal to zero. Respect this configuration when enforcing
the limits on object load.
Change-Id: Ic0f4ffcabf82105f8e690bd0eb5e6be485a313b3
Robin Rosenberg
Stefan Lay
Markus Duft
Colby Ranger
Shawn Pearce
Tomasz Zarna
Dani Megert
Roberto Tyley
Shawn Pearce
Dave Borowitz
Matthias Sohn
Tomasz Zarna