ResetCommand: Allow reset on unborn branch when ref not specified
In C Git 1.8.2, "git reset" now also works on an unborn branch (no HEAD
yet) if no explicit ref was specified. In that case, it is treated as a
reset to an empty tree.
This can be useful for callers because "unborn branch" no longer has to
be special-cased to "git rm --cached".
Bug: 414870
Change-Id: Ied750116f767518ae4d48823cf00752b049a8477
Signed-off-by: Robin Stocker <robin@nibor.org>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
With bug 391855, DirCacheEditor's PathEdit will be applied for each
stage. For an unmerged path, this would result in 3 equal entries for
the same path.
By using a DirCacheBuilder, the code is simpler and does not have the
above problem with unmerged paths.
Bug: 391860
Change-Id: I785deeaeb8474f8c7a7fbc9ef00d3131fac87e41
Signed-off-by: Chris Aniszczyk <zx@twitter.com>
ResetCommand: Correctly reset unmerged paths in resetIndexForPaths
The previous implementation used a PathEdit, which does not reset the
stage of the entry.
Bug: 391860
Change-Id: If26d3a35abfee85424ad69de724f06a28b6e9efb
Signed-off-by: Chris Aniszczyk <zx@twitter.com>
Write the old object id from the RefUpdate to the
ORIG_HEAD file after the update completes.
Add two new convenience methods to Repository to read
and write the ORIG_HEAD reference similar to the methods
for reading/writing CHERRY_PICK_HEAD and MERGE_HEAD.
Bug: 375525
Change-Id: I120b3b2cd3b1ddae88fce435285bae15cbf96f5e
Git API does not declare GitAPIException call() and related cleanups
All commands should throw a GitAPIException so new exceptions can be
added without breaking the builds of old code, i.e. anyone that calls
a Git API should catch GitAPIException and not just the currently known
exceptions.
Now the only checked exceptions on Git API calls are GitException and
subclasses of it. New checked exceptions that are subclasses of
GitException may be added without breaking the API.
Javadoc for GitAPIException is declared on GitCommand and
inherited to subclasses. JGitInternalException is not explicitly
documented anymore.
Unfortunately this change itself breaks the API. The intention is
that it shall be possible to add new checked subclasses of
GitAPIException without breaking the API.
Bug: 366914
EGit-Change-Id: I50380f13fc82c22d0036f47c7859cc3a77e767c5
Change-Id: I50380f13fc82c22d0036f47c7859cc3a77e767c5
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Overload DirCache.lock to take a repository that is
used for updating smudged index entries with information
from the repository's working tree.
New unit tests are also added for updating smudged index
entries on reset, checkout, and commit.
Change-Id: I88689f26000e4e57e77931e5ace7c804d92af1b6
When reset command was called with tag name as parameter the resulting
HEAD was set to the tag's SHA-1 which is a bug. This patch ensures that
repository.resolve() call always returns commit id.
Change-Id: I219b898c620a75c497c8652dbf4735fd094c4d7c
Signed-off-by: Dariusz Luksza <dariusz@luksza.org>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Throw JGit exception when ResetCommand got wrong ref
If the ResetCommand should reset to a invalid ref (e.g. HEAD in a repo
whithout a single commit) it was throwing an NPE. This is fixed now by
throwing a JGitInternalExcpeption. It would be nicer if we could throw
a InvalidRefException, but this would modify our API.
Bug: 339610
Change-Id: Iffcb4f2cca9f702176471d93c3a71e5cb3e700b1
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
Reset command should works recursively and allows reset all changed
files in given directory.
Bug: 348524
Change-Id: I441db34f226be36548c61cef77958995971498de
Signed-off-by: Dariusz Luksza <dariusz@luksza.org>
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
The reflog message fix was done in
I4f1c3cd6b2cf543be213f061afb94223062dde51
Change-Id: I44817ccf4bf226ed3e4ce6fb2d923e88788221dd
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>