Shawn O. Pearce [Sat, 18 Aug 2012 22:42:12 +0000 (15:42 -0700)]
Delete checkObjectCollisions from PackParser
This flag was added to provide an unsafe operation on the local
repository because the storage.dht code was too damn slow to provide
proper safe Git behavior all of the time. Now that stoarge.dht has
been removed from the repository, also delete this unsafe flag to
prevent applications from misusing the JGit library and permitting
users to potentially damage their local repository with bad data
received from an untrusted peer.
Change-Id: Ib1861c48bb74836731e7b7d57b635dd654b0dc66 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Shawn O. Pearce [Sat, 18 Aug 2012 22:27:12 +0000 (15:27 -0700)]
Delete storage.dht package
This experiment proved to be not very useful. I had originally
planned to use this on top of Google Bigtable, Apache HBase or
Apache Cassandra. Unfortunately the schema is very complex and
does not perform well. The storage.dfs package has much better
performance and has been in production at Google for many months
now, proving it is a viable storage backend for Git.
As there are no users of the storage.dht schema, either at Google or
any other company, nor any valid open source implementations of the
storage system, drop the entire package and API from the JGit project.
There is no point in trying to maintain code that is simply not used.
Change-Id: Ia8d32f27426d2bcc12e7dc9cc4524c59f4fe4df9 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Robin Stocker [Mon, 3 Sep 2012 06:44:28 +0000 (08:44 +0200)]
Add tests for more coverage of CheckoutCommand
Change-Id: Id3ab5f56f88d7e9636c71b30258c268a75fc422e Signed-off-by: Robin Stocker <robin@nibor.org> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Robin Stocker [Thu, 16 Aug 2012 14:06:58 +0000 (16:06 +0200)]
DirCacheCheckout: Fix handling of files not in index
When a file is not in the index and neither contents nor mode differ
between "head" and "merge", the index state should be kept. If they
differ, a checkout conflict should occur. This is described in Git's
git-read-tree.txt.
JGit used to replace the index state with "merge" in both of the above
cases.
A confusing effect of this was that when one removed a file and then did
a rebase, the file silently reappeared again.
The changes to dir/file conflict handling are a consequence of this
change, as the index handling change made tests in DirCacheCheckoutTest
break. I compared these cases to C Git and the new behavior there also
matches what C Git does.
Bug: 387390
Change-Id: I5beb781f12172a68f98c67d4c8029eb51ceae62d Signed-off-by: Robin Stocker <robin@nibor.org>
Robin Rosenberg [Sat, 1 Sep 2012 07:56:51 +0000 (09:56 +0200)]
Create an input stream that transforms LF to CRLF
The transformation is the same as AutoCRLFOutputStream does, but
the direction is reversed. The tests are reused, but the implementation
derives somewhat from the EolCanonicalizingInputStream.
This stream will be used to compare blobs with LF line endings with
worktree data that has CRLF line endings.
Bug: 387501
Change-Id: I80d96e453e7f780dd464a89778de124cf35384e1 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Enhance statistics for repo by sizes and ref-counts
The statistics for a repo now expose how many bytes are used in the
filesystem to store all loose/packed objects. The number of packed/loose
refs are also exposed.
In order to parse user specified strings containing date and time info
a thread-safe parser is implemented. This is needed for example to
interpret configuration parameters (e.g. gc.pruneexpire where need to
parse strings like "2 weeks ago"). The parser is thread-safe by caching
SimpleDateFormat instances in a ThreadLocal cache.
Native git has a parser called approxidate which is able to interpret a
huge number of formats ("1 year ago", "tea time", ...). Ideally JGit
should be able to parse the same strings as native git but for now this
parser understands the following subset:
Robin Rosenberg [Thu, 2 Aug 2012 22:56:46 +0000 (00:56 +0200)]
Set core.precomposeunicode to true when creating repository on Mac
Java has no option but to use precomposed Unicode, so we should
state that when creating a new repository. Not that Java will use
precomposed unicode regardless of this setting, but this reduces
the risk of incompatibility with C Git.
Robin Rosenberg [Tue, 21 Aug 2012 21:34:45 +0000 (17:34 -0400)]
Merge changes I98df46ce,Ifb815a12,I051a1724
* changes:
Support [<ref>]@{upstream} revision syntax
Support parsing previous checkout as a revision expresion.
Allow a @ without branch in revision syntax
JGit was not able to lookup refs which had the name of files which exist
in the .git folder. When JGit was looking up a ref named X it has a
fixed set of directories where it searched for files named X
(ignore packed refs for now). First directory to search for is .git. In
case of the ref named 'config' it searched there for this file, found it
(it's the .git/config file with the repo configuration in it), parsed
it, found it is an invalid ref and stopped searching. It never looked
for a file .git/refs/heads/config.
I changed JGit in a way that when it finds a file in GIT_DIR which
corresponds to a ref name and if this file doesn't contain a valid ref
then it will ignore the InvalidObjectIdException and continue searching.
Change-Id: Ic26a329fb1624a5b2b2494c78bac4bd76817c100
Bug: 381574 Signed-off-by: Christian Halstrick <christian.halstrick@sap.com> Signed-off-by: Stefan Lay <stefan.lay@sap.com>
Matthias Sohn [Fri, 17 Aug 2012 22:29:45 +0000 (00:29 +0200)]
Teach BranchTrackingStatus to handle tracking of local branches
EGit wasn't able to decorate local branches tracking another local
branch with number of commits the checked out local branch differs from
the other local branch it's tracking.
Bug: 376970
Change-Id: I74e932d5eacd74dbf6b0dffcfc65ba3222a8250e Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Robin Stocker [Fri, 17 Aug 2012 22:11:45 +0000 (00:11 +0200)]
Improve ours/theirs conflict markers for rebase, cherry-pick
On conflicts in rebase or cherry-pick, the conflict markers were like
this:
<<<<<<< OURS
a
=======
b
>>>>>>> THEIRS
This is technically correct, but it could be better.
It's especially confusing during a rebase, where the meaning of
OURS/THEIRS is not obvious. The intuition is that "ours" is the commits
that "I" did before the rebase, but it's the other way around because of
the way rebase works. See various bug reports and stackoverflow
discussions.
With this change, in the case of a cherry-pick while on master, the
markers will be like this:
<<<<<<< master
a
=======
b
>>>>>>> bad1dea Message of the commit I'm cherry-picking
In the case of a "git rebase master":
<<<<<<< Upstream, based on master
a
=======
b
>>>>>>> b161dea Message of a commit I'm rebasing
It's not "master" because that would only be correct for the first
cherry-pick during a rebase, after that, it's master + already
cherry-picked commits.
And in the case of a "git pull --rebase":
<<<<<<< Upstream, based on branch 'master' of git@example.org:repo
a
=======
b
>>>>>>> b161dea Message of a commit I'm rebasing
Bug: 336819
Change-Id: I1333a8dd170bb0077f491962013485efb6f2a926 Signed-off-by: Robin Stocker <robin@nibor.org> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Colby Ranger [Mon, 13 Aug 2012 22:54:06 +0000 (15:54 -0700)]
Implement wasDeltaAttempted() in DfsObjectRepresentation.
In DFS, everything is stored in a pack but only objects in a pack with
source GC or UNREACHABLE_GARBAGE have had delta compression attempted.
Expose the PackSource setter and getter on DfsPackDescription in order
to implement wasDeltaAttempted.
Colby Ranger [Mon, 13 Aug 2012 20:52:33 +0000 (13:52 -0700)]
Do not delta compress objects that have already tried to compress.
If an object is in a pack file already, delta compression will not
attempt to re-compress it. This assumes that the previous
packing already performed the optimal compression attempt, however,
the subclasses of StoredObjectRepresentation may use other heuristics
to determine if the stored format is optimal.
Markus Duft [Mon, 4 Jun 2012 13:37:53 +0000 (15:37 +0200)]
Make CheckoutCommand pass modified files through result
This change makes CheckoutCommand pass the list of modified files
through the OK result, enabling outside world to react in a smaller
scope (for example refresh only resources containing the modified
files).
Change-Id: I53c50ee09bc0d3ff501bdc25196e52e739c3f1f9 Signed-off-by: Chris Aniszczyk <zx@twitter.com>
Matthias Sohn [Fri, 18 May 2012 14:52:50 +0000 (16:52 +0200)]
Allow detection of case insensitive file systems
Change-Id: I03f59d07bcc3338ef8d392cbd940799186ca03bd Signed-off-by: Matthias Sohn <matthias.sohn@sap.com> Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Ensure a directory exists before trying to create/merge a file into it.
Since git doesn't keep track of empty directories, they should be
created first. Test case included demonstrates that using
StashApplyCommand(). Bugfix is applied to the DirCacheCheckout class,
because StashApplyCommand() uses it internally to apply a stash.
Change-Id: Iac259229ef919f9e92e7e51a671d877172bb88a8 Signed-off-by: Jevgeni Zelenkov <jevgeni.zelenkov@gmail.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Robin Rosenberg [Sun, 5 Aug 2012 10:50:06 +0000 (12:50 +0200)]
Fix PlotCommit for commits with duplicate parents
JGit allows to create commits which have duplicate parents: e.g. a
commit X has first parent Y and second parent Y. Such commits are not
handled correctly by PlotCommit leading to wrong display of the history
in EGit. In such cases there is a never ending passing line drawn beside
all commits younger than the commit with duplicate parents. This commit
fixes this by explicitly checking for duplicate parents.
In a different commit we should fix JGit not to create commits with
duplicate parents. I think native git also doesn't allow such commits,
although history display in native git (gitk, git log --graph) is not
damaged by such commits.
Implements a garbage collector for FileRepositories. Main ideas are
copied from the garbage collector for DFS based repos
(DfsGarbageCollector). Added functionalities are
- pruning loose objects
- handling of the index
- packing refs
- handling of reflogs (objects referenced from reflog will not be
pruned/)
These are features of a GC which are not handled in this change and
which should come with subsequent changes:
- unpacking packed objects into loose objects (to support that pruning
packed objects doesn't delete them until they are older than two weeks)
- expiration of reflogs
- support for configuration parameters (e.g. gc.pruneExpire)
Change-Id: I14ea5cb7e0fd1b5c50b994fd77f4e05bfbb9d911 Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Expose class DfsReader and method DfsPackFile.hasObject() as public.
Applications may want to be able to inquire about some details of
the storage of a repository. Make this possible by exposing some
simple accessor methods.
Expose method DfsObjDatabase.clearCache() as protected, allowing
implementing subclasses to dump the cache if necessary, and force
it to reload on a future request.
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 3ea694c2523d909190b5350e13254a62e94ec5d5 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>
Robin Rosenberg [Thu, 12 Jul 2012 06:04:35 +0000 (08:04 +0200)]
Support parsing previous checkout as a revision expresion.
Repository.resolve can only return an ObjectId and will
continue to do so, but another method, simplify(), will
be able to return a branch name for some cases.
Previous checkouts can be specified as @{-n}, where n is an
integer speifying the n:th previous branch. The result
is the branch name, unless the checkout was a detached head,
in which case the object id is returned. Since the result
is a branch it may be followed by a references to the reflog,
such as @{-1}@{1} if necessary.
A simple expression like "master" is resolved to master in
simplify, but anything starting with refs gets resolved to
its object id, even if it is a branch.
A symbolic ref is resolved to its leaf ref, e.g. "HEAD" might
be resolved to "master".
Markus Duft [Tue, 17 Jul 2012 16:32:38 +0000 (18:32 +0200)]
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>
Robin Rosenberg [Mon, 16 Jul 2012 21:47:46 +0000 (23:47 +0200)]
Allow a @ without branch in revision syntax
No branch before @ is interpreted as the currently checked out branch.
For detached heads it would be HEAD, but normally it is the branch
that HEAD refers to.
Improve performance of persisting an index by magnitudes
When updating smudged entries use a pathfilter to iterate only over
working tree files which have an associated smudged index entry.
Commit dac66672df0535f61a13273524d46e1e0012ca69 introduced that we
check and update smudged entries while persisting a dircache. Before
that commit adding a file to git caused file i/o for the index file,
the object database (to store new content) and all files we wanted to
add (to read new content). After that commit we have additionally file
i/o for every file in the working tree (even ignored files).
Especially on windows iterating over the working tree can be very
time consuming. This decreased the performance of persisting a dircache
dramatically (I measured factors 4 to 10 while adding a file to linux
kernel repo). One could easily see this effect when dragging&dropping
modified files in a linux kernel repo in the egit staging view.
Change-Id: I568dec77635013cf6bb46f652d3f2b89de041c82 Signed-off-by: Kevin Sawicki <kevin@github.com>
Shawn O. Pearce [Wed, 27 Jun 2012 18:06:37 +0000 (11:06 -0700)]
Work around smart HTTP bugs in C Git
I have unfortunately introduced a few bugs in the native Git client
over the years. 1.7.5 is unable to send chunked requests correctly,
resulting in corrupt data at the server. Ban this client whenever
it uses chunked encoding with an error message.
Prior to some more recent versions, git push over HTTP failed to
report status information and error messages due to a race within
the client and its helper process. Check for these bad versions and
send errors as messages before the status report, enabling users
to see the failures on their terminal.
Dave Borowitz [Wed, 27 Jun 2012 20:55:25 +0000 (13:55 -0700)]
Make InMemoryRepository pack names globally unique
It was easy to create multiple packs with exactly the same name and
same DfsRepositoryDescription in a test, which can poison the
DfsBlockCache. The javadoc for DfsObjDatabase.newPack() explicitly
says pack names should be unique within an entire DFS, so do this by
making the packId AtomicInteger static.
Arguably, test writers shouldn't be doing things like putting
'new DfsRepositoryDescription("test")' in a setUp() method, but that's
a natural thing to do, and we don't document this restriction
anywhere.
Robin Stocker [Mon, 4 Jun 2012 13:35:16 +0000 (15:35 +0200)]
Ignore empty lines when parsing git-rebase-todo
When starting a rebase with C Git, there may be empty lines in the
git-rebase-todo file. Before this change, JGit would fail to parse the
file with e.g. the following exception:
JGitInternalException: Unknown or unsupported command "
#", only "pick" is allowed.
This happened when there was an empty line just before the comments,
because the nextSpace would be the one from the comment. Now the empty
lines are ignored by checking for nextSpace < ptr outside of the loop.
Change-Id: I94ad299f367c846e7729c74f49c6b8f93f75ae81 Signed-off-by: Robin Stocker <robin@nibor.org>
Robin Stocker [Tue, 12 Jun 2012 17:03:52 +0000 (19:03 +0200)]
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>
Robin Stocker [Tue, 12 Jun 2012 16:12:14 +0000 (18:12 +0200)]
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>
Dave Borowitz [Wed, 20 Jun 2012 21:53:59 +0000 (14:53 -0700)]
Serve 403 from RepositoryFilter on ServiceMayNotContinueException
This has no effect on Git clients, but for browsers, 403 Forbidden may
be more appropriate. 500 Internal Server Error implies that there is
a problem with the server, whereas ServiceMayNotContinueException is
specifically intended to cover cases where the server is functioning
correctly but has determined that the request may not proceed.
Whenever a call to JGit returns a Repository the caller should make sure
to call close() on it if he doesn't need it anymore. Since instances of
Repository contain e.g. open FileOutputStreams (for pack files)
forgetting to close the repository can lead to resource leaks.
This was the reason why dozens of the JUnit tests failed on Windows
with "Can't delete file ...." errors.
In LocalDiskRepositoryTestCase.tearDown() we tried to delete the
repositories we used during tests which failed because we had open
FileOutputStreams.
Not only the obvious cases during Clone or Init operations returned
Repositories, but also the new SubModule API created repository
instances. In some places we even forgot to close submodule repositories
in our internal coding.
To see the effects of this fix run the JGit JUnit tests under Windows.
On other platforms it's harder to see because either the leaking
resources don't lead to failing JUnit tests (on Unix you can delete
files with open FileOutputStreams) or the java gc runs differently and
cleans up the resources earlier.
Change-Id: I6d4f637b0d4af20ff4d501db091548696373a58a Signed-off-by: Christian Halstrick <christian.halstrick@sap.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
LockFileTest was failing on Windows because we couldn't delete the lock
file of the index. The reason was that a LockFile instance still had an
open handle to the lock file preventing us to delete the file (in
contrast to the behavior on other platforms).
Change-Id: I1d50442b7eb8a27f98f69ad77c5e24a9698a7b66 Signed-off-by: Christian Halstrick <christian.halstrick@sap.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Dave Borowitz [Thu, 14 Jun 2012 22:07:13 +0000 (15:07 -0700)]
Read .gitmodules config from the tree in SubmoduleWalk
It is not always appropriate to use the .gitmodules file from the
working tree, for example if reading the modules at a specific commit.
And sometimes it is impossible, as in a bare repository.
When using the static factory methods, automatically set up the
appropriate root tree so lazy loading of the config file reads from
the appropriate place. Leave the current behavior of looking in the
working tree as a fallback for the case where walking the index.
Dave Borowitz [Thu, 14 Jun 2012 22:06:09 +0000 (15:06 -0700)]
Add a release() method to SubmoduleWalk
We need a way to release the underlying TreeWalk. Also, use this
method to release walks from the static factory methods on error or
when submodules are not found.
projects / jgit.git / log