Really handle annotated tags in MergeCommand

Repository.peel() must be called to ensure a tag is really peeled.

Change-Id: I83e25f09fad3ad55a3ffe41ab4758f249b7ac9f9
Fix Config.fromText to not skip a last line with no newline

Change-Id: Id6da6ff19296410806282bb7419fd8455e8c5475
Implement core.checkstat = minimal

There is a huge performance issue when using both JGit (EGit) and Git
because JGit does not fill all dircache stat fields with the values Git
would expect. As a result thereof Git would typically revalidate a large
number of tracked files. This can take several minutes for large
repositories with many large files.

Since 1.8.2 Git will restrict stat checking to the size and whole second
part of the modification time stamp, if core.statinfo is set to
"minimal".

As JGit checks only size and modification time this is close to what
JGit already does. To make the match perfect ignore the sub-second part
of the modification time stamp if core.statinfo = minimal.

Change-Id: I8eaff1858a891571075a86db043f9d80da3d7503
Remove unused availableRefs local from Clone.guessHEAD

This variable has been populated and never used ever since it was
introduced in v0.4.9~336 (Add "jgit clone", 2008-12-23).  Remove it
to make the function easier to understand.

Change-Id: Idb7eb80bc236a20f7385ad2d6141b4d1c5c3f1cc
Merge "Remove unused availableRefs local from Clone.guessHEAD"
Merge branch 'stable-2.3'

* stable-2.3:
  Prepare post 2.3.0.201302130906 builds
  JGit v2.3.0.201302130906
  Replace explicit version by property where possible
  Add better documentation to DirCacheCheckout
  Prepare post 2.3rc1 builds
  JGit v2.3.0.201302060400-rc1

Change-Id: I5a7626014dc38e7623937a4241dbf8a6db05c1f9
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Remove unused imports

These imports are unused since commit
cb349da0174e77cc751e6cb8a16b327c4976b993

Change-Id: I74ea2a17bf4976d9c74255500e5deeff18208e87
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Cleanup unused imports

Change-Id: I7fe51f4a6187c32c917b2f503d6b50d0d6b28a61
Merge "Cleanup unused imports"
Prepare 2.4.0-SNAPSHOT builds

Change-Id: I4ab2baeb5d598d40d5dadfccdfe75152a1b9b7bf
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Merge "Prepare 2.4.0-SNAPSHOT builds"
Add the --branch flag to the jgit clone command

--branch or -b allows the user to specify which branch to checkout after
clone.

Change-Id: Ie27533e5ecb43097862a8337a27a742b501e17a5
Must use double single quotes around parameters

Change-Id: I34da782e6b9a492e3e291b36ef82f06ce8347660
Merge branch 'stable-2.3'

* stable-2.3:
  Prepare 2.3.2-SNAPSHOT builds
  JGit v2.3.1.201302201838-r
  Accept Change-Id even if footer contains not well-formed entries
  Fix false positives in hashing used by PathFilterGroup

Change-Id: I5882aa3b482d6bcd40a45bed51e5ab03f018a5bc
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Fix off by one error in PackReverseIndex.

The last 32bit offset is at Integer.MAX_VALUE.

Change-Id: Idee8be3c7887e1d0c8339ff94aceff36dbf000db
Improve the documentation of the ByteArraySet used by PathFilterGroup

Change-Id: I2ba7a67e8e1596aa6c33a9caddee03a6be48f008
Implement recursive merge strategy

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>
Deploy Maven artifacts to Eclipse Nexus repository

Bug: 401469
Bug: 401470
Change-Id: I4901dc208fe8f9e4055d27ab7e0ced979fd234f5
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Update last release version to 2.3.1.201302201838-r

Change-Id: I9c6d774526028e56707e15e80370460d964de76e
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Performance fixes in DateRevQueue

When a lot of commits are added to DateRevQueue, the
sort-on-insertion approach is very heavy on CPU cycles.

One approach to fix this was made by Dave Borowitz:
https://git.eclipse.org/r/#/c/5491/

But using Java's PriorityQueue seems to have brought some
extra overhead, and the desired performance could not be
reached.

This fix takes another approach to the insertion problem,
without changing the expected behaviour or bringing extra
memory overhead:

If we detect over 1000 commits in the DateRevQueue, a
"seek-index" is rebuilt every 1000th added commit.

The index keeps track of every 100th commit in the
DateRevQueue. During insertions, it will be used for a
preliminary scanning (binary search) of the queue, with
the intention of helping add() find a good starting point
to start walking from. After finding this starting point,
add() will step commit-by-commit until the correct
insertion place in the queue is found (today, the queue
is expected to be sorted at all times).

When applied to repositories with many refs, this approach
has proven to bring huge performance gains and scales quite
well.

For instance, in a repository with close to 80000 refs,
we could cut down the time a typical Gerrit replication
of 1 commit would take (just a push from JGit's point of
view) from 32sec down to 3.5sec.

Below you see some typical times to add a specific amount
of commits (with random commit times) to the DateRevQueue
and the difference the preliminary seek-index makes:

Commits | Index | No Index
   1024     8ms        8ms
   2048    13ms        9ms
   4096     5ms       59ms
   8192    11ms      595ms
  16384    22ms     3058ms
  32768    64ms    13811ms
  65536   201ms    62677ms
 131072   783ms   331585ms

Only one extra reference is needed for every 100 inserted
commits (and only when we see more than 1000 commits in
the queue), so the memory overhead should be negligible.

Various index-stepping values were tested, and 100 seemed to
scale very well and be effective from start.

In the future, it should probably be dynamic and based on
the number of refs in the queue, but this should serve well
as a starting point.

Note: While other fundamentally different data structures may
be more suitable, the DateRevQueue is extremely central to
many of the Git core operations. This approach was chosen,
since the effect of the patch is easy to predict in conjuction
with the current implementation. A totally new data structure
will make it harder to predict behaviour in many common and
uncommon cases (in terms of breaking ties, memory usage, cost
when using few elements, object creation/disposing overhead,
etc).

Change-Id: Ie7b99f40eacf6324bfb4716d82073adeda64d10f