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>

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>

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.

Change-Id: I335a4c7630a2629a86f13a2a5cd99f79a2c2afa4

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:

"now"
"yesterday"
"(x) years|months|weeks|days|hours|minutes|seconds ago"
"yyyy-MM-dd HH:mm:ss Z" (ISO)
"EEE, dd MMM yyyy HH:mm:ss Z" (RFC)
"yyyy-MM-dd"
"yyyy.MM.dd"
"MM/dd/yyyy"
"dd.MM.yyyy"
"EEE MMM dd HH:mm:ss yyyy Z" (DEFAULT)
"EEE MMM dd HH:mm:ss yyyy" (LOCAL)

Change-Id: Iccb66dadb60da13104e73140e53d5e2de068369c

The Jetty 7.x p2 repository was moved to the archive server

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

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

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

EGit should be able to continue a rebase started by C Git.

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

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

Change-Id: Id0b8aef92f10572d4f1ec198e0281162fcd7ed4e

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.

Change-Id: I3779b75f76d2e2061c836cbc9b4b7c2ae0cf18f4

Change-Id: I34e9ba4a26f7af5b88140c070f02a7990f1941af

* changes:
  Support [<ref>]@{upstream} revision syntax
  Support parsing previous checkout as a revision expresion.
  Allow a @ without branch in revision syntax

* changes:
  The Git API's only likes /, not \ in paths
  Skip a test that cannot be verified on Windows

Therefore this test fails on Windows

Change-Id: I4f73487b720ea1479e95108344f1dc3711106408

Change-Id: I1d1ed122c714f39ca7fb557224756205274804eb

The method uses some heuristics to obtain much better performance
than isMergeBase.

Since I wrote the relevant code in the method I approve the license
change from EPL to EDL implied by the move.

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

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>

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>

* changes:
  Implement wasDeltaAttempted() in DfsObjectRepresentation.
  Do not delta compress objects that have already tried to compress.

idOffset is not zero when idBuffer comes from blob in the dircache

Change-Id: Iff768422cba140a5d6a776e2c627b852f079c1da

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.

Change-Id: Ie949f321147ad870f1c3f23b552343bbbda32152

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.

Change-Id: I403de522f4b0dd2667d54f6faed621f392c07786

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>

C Git prefixes the time stamp in the author script with a "@"

Change-Id: I140b29519acc101da78296eef562368fc6b61135

Change-Id: I03f59d07bcc3338ef8d392cbd940799186ca03bd
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>

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>

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.

Change-Id: Ie3019ef613a507023958bea27b1badc3b8950279

The wordings of the two license are the same. This change is there
to make this file consistent with the LICENSE file.

Change-Id: I7c9d7a8f3622dd4099ca311af3dd032034bf56c0

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.

Change-Id: Ic592c82d45ace9f2fa5f8d7e4bacfdce96dea969

A configured remote url like "../repo" works with C Git.

In JGit, it only worked if Java's current working directory happened to
be the local repository working directory.

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

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>

This reverts commit 3ea694c252

Merges with unmodified subtrees are broken with this commit present.
Back it out until a fixed version can be supplied.

Resolves into a ref name corresponding to the named (or current)
branch's upstream ref.

Change-Id: I98df46cedb498724cf14343fbb168f24ff667929

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".

Change-Id: Ifb815a1247ba2a3e2d9c46249c09be9d47f2b693