Allow adding single refs or all tags to NameRevCommand

Change-Id: I90e85bc835d11278631afd0e801425a292578bba

Merge "Cluster UNREACHABLE_GARBAGE packs at the end of the search list"

Merge "Avoid repacking unreachable garbage in DfsGarbageCollector"

Merge changes Icd550359,If7aad533

* changes:
  Avoid looking at UNREACHABLE_GARBAGE for client have lines
  Simplify UploadPack by parsing wants separately from haves

Merge "Add a NameRevCommand for describing IDs in terms of refnames"

Add a NameRevCommand for describing IDs in terms of refnames

The walk logic does not use RevWalk because it needs to walk all paths
to each of the requested commits, keeping track of each path along which
the commit was found in the RevCommit subclass. From these paths, a
single "best" path is chosen based on the total path length, with a
penalty applied for paths that traverse merges.

This functionality parallels "git name-rev".

Change-Id: I92bfb47dd16c898313d2ee525395609c3bf72ebe

Add isRebasing to RepositoryState

See EGit change Ic69f5c952a49f023c0949f04b3e976be1b267fbe where this
could be used.

Change-Id: I9ec8568fa1100d2e9c8d4ca0e347bf77ec6d8734

Avoid looking at UNREACHABLE_GARBAGE for client have lines

Clients send a bunch of unknown objects to UploadPack on each round
of negotiation. Many of these are not known to the server, which
leads the implementation to be looking at indexes for garbage packs.

Disable examining the index of a garbage pack, allowing servers to
avoid reading them from disk during negotiation.

The effect of this change is the server will only ACK a have line
if the object was reachable during the last garbage collection,
or was recently added to the repository. For most repositories
there is no impact in this behavior change.

If a repository rewinds a branch, runs GC, and then resets the
branch back to where it was before, the now current tip is going to
be skipped by this change. A client that has the commit may wind up
getting a slightly larger data transfer from the server as an older
common ancestor will be chosen during negotiation. This is fixable
on the server side by running GC again to correct the layout of
objects in pack files.

Change-Id: Icd550359ef70fc7b701980f9b13d923fd13c744b

Simplify UploadPack by parsing wants separately from haves

The DHT backend was very slow at parsing objects. To work around
that performance limitation I obfuscated UploadPack by folding both
the want and have sets together in a single parse queue. Since DHT
was removed the complexity is no longer constructive to JGit.

Doing this refactoring prepares the code for a slightly future
change where the have lines need to be handled specially from the
want lines. Splitting the parsing up into two phases makes such
a modification trivial.

Change-Id: If7aad533b82448bbb688278e21f709282e5ccf4b

Cluster UNREACHABLE_GARBAGE packs at the end of the search list

Garbage is unlikely to be used by a reader. Ensure they always
cluster at the end of the search list, no matter what timestamp
was used on the pack files.

Change-Id: I3bed89e9569ee3363c36bb3f73fcd34057a3883f

Avoid repacking unreachable garbage in DfsGarbageCollector

If a repository has significant amounts of unreachable garbage the
final phase to coalesce it can take longer than any other part of the
garbage collection phase. Provide a setting for applications to tweak
the threshold where coalescing ends and files just remain on disk.

Change-Id: I5f11a998a7185c75ece3271d8bc6181bb83f54c1

Include the number of ms in timeout error message

Noticed that while analyzing bug 402131.

Change-Id: If3fd40b64d5088c4579946271a67346cbd9e6556

Do not cherry-pick merge commits during rebase

Rebase computes the list of commits that are included in
the merges, just like Git does, so do not try to include
the merge commits. Re-recreating merges during rebase is
a bit more complicated and might be a useful future extension,
but for now just linearize during rebase.

Change-Id: I61239d265f395e5ead580df2528e46393dc6bdbd
Signed-off-by: Robin Stocker <robin@nibor.org>

Extend FileUtils.delete with option to delete empty directories only

The new option EMPTY_DIRECTORIES_ONLY will make delete() only delete
empty directories. Any attempt to delete files will fail. Can be
combined with RECURSIVE to wipe out entire tree structures and
IGNORE_ERRORS to silently ignore any files or non-empty directories.

Change-Id: Icaa9a30e5302ee5c0ba23daad11c7b93e26b7445
Signed-off-by: Robin Stocker <robin@nibor.org>

Add javaewah bundle to features using it

This ensures that OSGi consumers can retrieve this dependency from the
JGit or EGit p2 repository.

Change-Id: I6f88a4914a19e4e18aa60d59b0cc8a33b61f7fc2
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Do not attempt to read bitmap from invalid pack

If a pack file has been marked invalid due to a prior IOException
accessing its contents, do not offer its bitmap index to callers.
The pack cannot be used so its bitmap should be off limits from
any reader trying to work from a bitmap.

Change-Id: Ia44e46558abdddee560bb184158b1e0af9437eee

Rename DfsPackFile getBitmap method to match PackFile

There is no reason for these to differ in name. Match the
shorter name used by PackFile.

Change-Id: I2d3a299069acc5ce276b1b5439ff2258903c6ff3

Write the bitmap index correctly in DFS GC.

A bug caused the .bitmap to actually have the .idx contents.

Change-Id: I428bb27d419e8b1b69b6f3e2fd07cd29703669ad

Enable writing bitmaps during GC by default.

Bitmaps provide a huge performance boost for counting objects and they
play nice with the cgit implementation.

Change-Id: I33b05a6c8f1ee2df7770f0b9fdc50d0b4bbf1029

Enable writing pack indexes with bitmaps in the GC.

Update the dfs and file GC implementations to prepare and write
bitmaps on the packs that contain the full closure of the object
graph. Update the DfsPackDescription to include the index version.

Change-Id: I3f1421e9cd90fe93e7e2ef2b8179ae2f1ba819ed

Enable serving upload requests using bitmaps.

If the pack index has bitmaps, allow the PackWriter to use the bitmaps
for upload requests.

Change-Id: Iefa995fe927a11e4fd78afb34530995614221fc0

Support creating pack bitmap indexes in PackWriter.

Update the PackWriter to support writing out pack bitmap indexes,
a parallel ".bitmap" file to the ".pack" file.
Bitmaps are selected at commits every 1 to 5,000 commits for
each unique path from the start. The most recent 100 commits are
all bitmapped. The next 19,000 commits have a bitmaps every 100
commits. The remaining commits have a bitmap every 5,000 commits.
Commits with more than 1 parent are prefered over ones
with 1 or less. Furthermore, previously computed bitmaps are reused,
if the previous entry had the reuse flag set, which is set when the
bitmap was placed at the max allowed distance.

Bitmaps are used to speed up the counting phase when packing, for
requests that are not shallow. The PackWriterBitmapWalker uses
a RevFilter to proactively mark commits with RevFlag.SEEN, when
they appear in a bitmap. The walker produces the full closure
of reachable ObjectIds, given the collection of starting ObjectIds.

For fetch request, two ObjectWalks are executed to compute the
ObjectIds reachable from the haves and from the wants. The
ObjectIds needed to be written are determined by taking all the
resulting wants AND NOT the haves.

For clone requests, we get cached pack support for "free" since
it is possible to determine if all of the ObjectIds in a pack file
are included in the resulting list of ObjectIds to write.

On my machine, the best times for clones and fetches of the linux
kernel repository (with about 2.6M objects and 300K commits) are
tabulated below:

Operation                   Index V2               Index VE003
Clone                       37530ms (524.06 MiB)     82ms (524.06 MiB)
Fetch (1 commit back)          75ms                 107ms
Fetch (10 commits back)       456ms (269.51 KiB)    341ms (265.19 KiB)
Fetch (100 commits back)      449ms (269.91 KiB)    337ms (267.28 KiB)
Fetch (1000 commits back)    2229ms ( 14.75 MiB)    189ms ( 14.42 MiB)
Fetch (10000 commits back)   2177ms ( 16.30 MiB)    254ms ( 15.88 MiB)
Fetch (100000 commits back) 14340ms (185.83 MiB)   1655ms (189.39 MiB)

Change-Id: Icdb0cdd66ff168917fb9ef17b96093990cc6a98d

Added read/write support for pack bitmap index.

A pack bitmap index is an additional index of compressed
bitmaps of the object graph. Furthermore, a logical API of the index
functionality is included, as it is expected to be used by the
PackWriter.

Compressed bitmaps are created using the javaewah library, which is a
word-aligned compressed variant of the Java bitset class based on
run-length encoding. The library only works with positive integer
values. Thus, the maximum number of ObjectIds in a pack file that
this index can currently support is limited to Integer.MAX_VALUE.

Every ObjectId is given an integer mapping. The integer is the
position of the ObjectId in the complete ObjectId list, sorted
by offset, for the pack file. That integer is what the bitmaps
use to reference the ObjectId. Currently, the new index format can
only be used with pack files that contain a complete closure of the
object graph e.g. the result of a garbage collection.

The index file includes four bitmaps for the Git object types i.e.
commits, trees, blobs, and tags. In addition, a collection of
bitmaps keyed by an ObjectId is also included. The bitmap for each entry
in the collection represents the full closure of ObjectIds reachable
from the keyed ObjectId (including the keyed ObjectId itself). The
bitmaps are further compressed by XORing the current bitmaps against
prior bitmaps in the index, and selecting the smallest representation.
The XOR'd bitmap and offset from the current entry to the position
of the bitmap to XOR against is the actual representation of the entry
in the index file. Each entry contains one byte, which is currently
used to note whether the bitmap should be blindly reused.

Change-Id: Id328724bf6b4c8366a088233098c18643edcf40f

Merge "Break the dependency on RevObject when creating a newObjectToPack()."

Merge "Fix RefUpdate performance for existing Refs"

Merge "Fix corrupted CloneCommand bare-repo fetch-refspec (#402031)"

Break the dependency on RevObject when creating a newObjectToPack().

Update the ObjectReuseAsIs API to support creating new
ObjectToPack with only the AnyObjectId and Git object type. This is
needed to support the future pack index bitmaps, which only contain
this information and do not want the overhead of creating a temporary
object for every ObjectId.

Change-Id: I906360b471412688bf429ecef74fd988f47875dc

Merge "Remove the unused method PackFile.hasExt()."

Remove the unused method PackFile.hasExt().

It will be used in a future change, so just include it with that change.

Change-Id: I7db28d86f8e8b282a403acd9a4c4defaae828f94

Fix corrupted CloneCommand bare-repo fetch-refspec (#402031)

CloneCommand has been creating fetch refspecs like this on bare clones:

[remote "origin"]
        url = ssh://example.com/my-repo.git
        fetch = +refs/heads/*:refs/heads//*

As you can see, the destination ref pattern has a superfluous slash.

It looks like this behaviour has always been the case for CloneCommand,
at least since cc2197ed when code catering to bare-clone fetch refspecs
was added. That was released with JGit v1.0 almost 2 years ago, so
there will probably be some bare repos in the wild which will have been
cloned with JGit and have these corrupted refspecs.

The effect of the corrupted fetch refspec is quite interesting. Up to
and including JGit 2.0, the corrupt refspec was tolerated and fetches
would work as intended with no indication to the user that anything was
amiss. With JGit 2.1, a change was introduced which made JGit less
tolerant, and fetches now attempt to update the non-existing ref
"refs/heads//master". No exception is raised, but the real ref -
"refs/heads/master" - is not updated.

This behaviour was noticed by a user of Agit (which does bare clones by
default and recently updated from JGit v2.0 to v2.2), reported here:

https://github.com/rtyley/agit/issues/92

If you run C-Git fetch on a bare-repo cloned by JGit, it flat-out
rejects the refspec (checked against v1.7.10.4):

fatal: Invalid refspec '+refs/heads/*:refs/heads//*'

Incidentally, C-Git does not create an explicit fetch refspec at all
when performing a bare clone - the full remote config generated by C-Git
looks like this:

[remote "origin"]
        url = ssh://example.com/my-repo.git

Using JGit on such a repository works fine, so omitting the fetch
refspec entirely is also an option.

Change-Id: I14b0d359dc69b8908f68e02cea7a756ac34bf881

Fix RefUpdate performance for existing Refs

No longer invoke the expensive RefDatabase.isNameConflicting() check on
updating existing refs, reducing batch ref update time by ~97%.

The RefDirectory implementation of isNameConflicting() is quite
slow (it has to do an expensive loose-ref scan) but it's only necessary
to perform this check on ref update if the ref is being *created* - if
the ref already exists, we can already guarantee that it does not
conflict with any other refs.

C-Git seems to use a similar condition before making the
is_refname_available() check:

https://github.com/git/git/blob/v1.8.1.4/refs.c#L1660-L1670

As an example of the effects on performance, here's a simple timing
experiment using The BFG to remove one file from the JGit repo:

---
$ wget http://repo1.maven.org/maven2/com/madgag/bfg-repo-cleaner/1.0.1/bfg-1.0.1.jar
$ git clone --mirror https://git.eclipse.org/r/p/jgit/jgit.git
$ java -jar bfg-1.0.1.jar -D make_jgit.sh jgit.git
....
Updating references:    100% (5760/5760)
...Ref update completed in 148,949 ms.

BFG run is complete!
---

The execution time for the run is completely dominated by the batch ref
update at the end. Repeating the experiment with BFG v1.0.2 (using JGit
patched with this change), the refs update is dramatically reduced:

---
Updating references:    100% (5760/5760)
...Ref update completed in 4,327 ms.
---

Change-Id: I9057bc4ee22f9cc269b1cc00c493841c71527cd6

Merge "Improve the documentation of the ByteArraySet used by PathFilterGroup"

Include supported extensions in PackFile constructor.

Previously a PackFile class was assumed to only support a .pack and .idx
file. Update the constructor to enumerate the supported extensions for
the pack file. This will allow the bitmap code to only be executed if
the bitmap extension file is known to exist.

Change-Id: Ie59041dffec5f60d7ea2771026ffd945106bd4bf

Fix while boundries in DateRevQueue.add()

In add(), "low" will never equals "first". This fact
should be reflected in the code.

Change-Id: I5cab51374e67bd2d3301e5d9dac47c4259b5e562

Merge "Performance fixes in DateRevQueue"

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

Update last release version to 2.3.1.201302201838-r

Change-Id: I9c6d774526028e56707e15e80370460d964de76e
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>

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>

Improve the documentation of the ByteArraySet used by PathFilterGroup

Change-Id: I2ba7a67e8e1596aa6c33a9caddee03a6be48f008

Fix off by one error in PackReverseIndex.

The last 32bit offset is at Integer.MAX_VALUE.

Change-Id: Idee8be3c7887e1d0c8339ff94aceff36dbf000db

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>

Prepare 2.3.2-SNAPSHOT builds

Change-Id: I51a8a53194928416b1aef1f3fce0ce66aadceca4
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

JGit v2.3.1.201302201838-r

Change-Id: I0d79873137ad4042ecc2a0210fe1f6305608b851
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Merge "Accept Change-Id even if footer contains not well-formed entries" into stable-2.3

Accept Change-Id even if footer contains not well-formed entries

Instead of only looking for a Change-Id in the last section if it
consists only of well-formed "key: value" lines replace the last
occurrence of a valid Change-Id line in the last section. Some tools
require footer lines e.g. without a colon.

Gerrit doesn't accept Change-Id lines in the footer if the Change-Id
line doesn't start at the beginning of the line.

Bug: 400818
Change-Id: Icce54872adc8c566994beea848448a2f7ca87085
Signed-off-by: Stefan Lay <stefan.lay@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Fix false positives in hashing used by PathFilterGroup

The ByteArraySet failed to check the length of the entry correctly leading
to matches where no match should be.

Bug: 401249
Change-Id: I925bc48d9cafcdf13e1a797bb09fc2555eb270c5
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>

Must use double single quotes around parameters

Change-Id: I34da782e6b9a492e3e291b36ef82f06ce8347660

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

Merge "Prepare 2.4.0-SNAPSHOT builds"

Prepare 2.4.0-SNAPSHOT builds

Change-Id: I4ab2baeb5d598d40d5dadfccdfe75152a1b9b7bf
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Merge "Cleanup unused imports"

Cleanup unused imports

Change-Id: I7fe51f4a6187c32c917b2f503d6b50d0d6b28a61

Remove unused imports

These imports are unused since commit
cb349da0174e77cc751e6cb8a16b327c4976b993

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

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>

Prepare post 2.3.0.201302130906 builds

Change-Id: Ia11b4000557d0cf235c4e33cda4539cab25fef47
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Merge "Remove unused availableRefs local from Clone.guessHEAD"

JGit v2.3.0.201302130906

Change-Id: If2e5fcbc01c2a7f058ef13d60b0bba5f77300d52
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Replace explicit version by property where possible

Change-Id: Ibb3b983d01133fd98477d9284118d8220846f0e9
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

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

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

Fix Config.fromText to not skip a last line with no newline

Change-Id: Id6da6ff19296410806282bb7419fd8455e8c5475

Really handle annotated tags in MergeCommand

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

Change-Id: I83e25f09fad3ad55a3ffe41ab4758f249b7ac9f9

Add better documentation to DirCacheCheckout

Change-Id: I282b702d9e4cb19063d8e9503604538f80e955b7
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>

Prepare post 2.3rc1 builds

Change-Id: I5c7daa5a735bfc2ecb9adc11c392b94d235102b6
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

JGit v2.3.0.201302060400-rc1

Change-Id: Id1f1d174375f7399cee4c2eb23368d4dbb4c384a
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Add getConflictingNames to RefDatabase

This has the same logic as isNameConflicting, but instead of only
returning a boolean, it returns a collection of names that conflict.

It will be used in EGit to provide a better message to the user when
validating a ref name, see Ibea9984121ae88c488858b8a8e73b593195b15e0.

Existing implementations of isNameConflicting could be rewritten like
this:

  return !getConflictingNames(name).isEmpty();

But I'm not sure about that, as isNameConflicting can be implemented in
a faster way than getConflictingNames.

Change-Id: I11e0ba2f300adb8b3612943c304ba68bbe73db8a
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Move base test classes to the junit bundle for reuse for Java 7 tests

Change-Id: Iedb54eb9d8396bc3ae66d8754c1527fd9ca655f9

Merge "Extract method to output the first header line of a git diff"

Fixed problems occuring when changing user in gerrit configuration

Bug: 399238
Change-Id: I255634bc9b3681f292190051daed22a4771d6e57
Signed-off-by: Tobias Pfeifer <to.pfeifer@sap.com>

Update to latest orbit release

Update 3rd party dependencies to respective latest approved version.

args4j 2.0.21 is not yet available on Maven central, hence compile
against 2.0.12 and package 2.0.21 until 2.0.21 has been published on
Maven central.

Change-Id: I41a34485970af41b4b5b2404e3d29c98979ddb48
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Remove PathFilterGroupTest2

The test is not very useful for regression testing in its current form

Change-Id: I19d1a29ff693397ac795d414b83411f32fae56d8

Remove debug printouts from PathFilterGroupTest

Change-Id: I4767e53efafe48d447ebe399fb2f8617072950ea

Fix stash apply using merge logic

Instead of the complicated strange stuff, implement staah
apply as cherry-pick.

Provided there are no conflicts and it is requested that
the index should be applied, perform yet another cherry-pick,
but discard tha results thereof it that would result in conflicts.

Bug: 376035
Change-Id: I553f3a753e0124b102a51f8edbb53ddeff2912e2

Extract method to output the first header line of a git diff

In order to be able to determine the range of the first header line
(e.g. "diff --git a/file1 b/file2") in subclasses, the code that formats
the first header line is extracted.

Required by egit's change: Ia61398146c0336ab332234f24d341561292554db

Change-Id: I9dd5eb964ed8b6869745c3162159b7425ac2c44a
Signed-off-by: Tobias Pfeifer <to.pfeifer@sap.com>

Merge "Align execution environment with JRE on the classpath in jgit.ant.test"

Fix Check for FF_ONLY merges again

Added more FF-mode tests

Change-Id: I33eed5737d9411cc1cf214da62ce719916a1b736

Merge "Check for FF_ONLY merges correctly"

Merge changes Ife0cc2da,If38507ef

* changes:
  Speed up PathFilterGroup for large sets of paths
  Add test case for PathFilterGroup

Check for FF_ONLY merges correctly

Bug: 398192
Change-Id: I1253c0ea0632185bbf9f77e32f13ba5842a6e18e

Align execution environment with JRE on the classpath in jgit.ant.test

Change-Id: Ic11ddce81dbcc7d703742c7e86941d2f43668617

Merge changes I25204d9e,Ia10d76e9

* changes:
  Attempt to stabilize GCTest
  Attempt to stabilize FileTreeIterator test on Windows

Attempt to stabilize GCTest

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

Attempt to stabilize FileTreeIterator test on Windows

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

Merge "Reduce memory held and speed up DfsGarbageCollector."

Reduce memory held and speed up DfsGarbageCollector.

getObjectList() returns a list of ObjectToPack. These can hold on to a
lot of memory. Furthermore, binary searching for objects in a sorted
array can be slow. Improve the speed and reduce the memory by creating a
copy of the ObjectId and inserting it into an ObjectIdOwnerMap.

Change-Id: Ib5aa5b7447e05938b47fa55812a87b9872c20ea7

Enable marking entries using TreeFilters in DiffEntry

This adds a new optional TreeFilter[] argument to DiffEntry.scan. All
filters will be checked during the scan to determine if an entry should
be "marked" with regard to that filter.

After having called scan, the user can then call isMarked(int) on the
entries to find out whether they matched the TreeFilter with the passed
index.

An example use case for this is in the file diff viewer of EGit's
History view, where we'd like to highlight entries that are matching the
current filter.

See EGit change I03da4b38d1591495cb290909f0e4c6e52270e97f.

Bug: 393610
Change-Id: Icf911fe6fca131b2567514f54d66636a44561af1
Signed-off-by: Robin Stocker <robin@nibor.org>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Add new committers

Change-Id: I5ef1edb8efc4668ef4731094ea6dbbcaf200195d
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Update to jsch 0.1.46

Change-Id: Ib7eb1ff175e3f9763653b0b0432b8ddc6b1c8938
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Merge "Fix NPE FS_Win32 when looking up git executable and home directory avoiding redundant code"

Speed up PathFilterGroup for large sets of paths

The ByteArraySet is a distorted copy of ObjectIdSubclassMap.

Bug: 397185
Change-Id: Ife0cc2da6cc46431be94a6b14f64f6adbe983afb

Add test case for PathFilterGroup

This is needed to prepare for optimization.

Bug: 397185
Change-Id: If38507ef8cc5a161353cc07bf7cd1922f54d1f8a

Merge "Improve handling of checkout conflicts"

Merge changes I7e7fae12,I87ecca00

* changes:
  Add conflicts message before footer
  Only replace the ChangeId in the footer, not in the body

Add conflicts message before footer

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

Only replace the ChangeId in the footer, not in the body

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>

Merge "Use correct method link in Javadoc"

Merge "Fix patch application WRT windows line endings."

Fix patch application WRT windows line endings.

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

Merge "Update DfsGarbageCollector to not read back a pack index."