Use Instant instead of milliseconds for filesystem timestamp handling
This enables higher file timestamp resolution on filesystems like ext4,
Mac APFS (1ns) or NTFS (100ns) providing high timestamp resolution on
filesystem level.
Note:
- on some OSes Java 8,9 truncate milliseconds, see
https://bugs.openjdk.java.net/browse/JDK-8177809, fixed in Java 10
- UnixFileAttributes truncates timestamp resolution to microseconds when
converting the internal representation to FileTime exposed in the API,
see https://bugs.openjdk.java.net/browse/JDK-8181493
- WindowsFileAttributes also provides only microsecond resolution
Change-Id: I25ffff31a3c6f725fc345d4ddc2f26da3b88f6f2
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Also check that reflog is enabled by default.
Also check that a file in a folder is reset correctly.
Change-Id: I4bc6649928ce10d7b558901e465e8032b083ade0
Signed-off-by: René Scheibe <rene.scheibe@gmail.com>
Use existing test utility methods instead of nested PrintWriter usage.
Change-Id: I324852c7971ae644fa499f377a31d1cf265c7fd9
Signed-off-by: René Scheibe <rene.scheibe@gmail.com>
Renamed and restructured tests for improved clarity.
Bug: 479266
Change-Id: Ic9d05ddf722bddd148fa9d9c19248dd53d97f1e4
Signed-off-by: René Scheibe <rene.scheibe@gmail.com>
Open auto-closeable resources in try-with-resource
When an auto-closeable resources is not opened in try-with-resource,
the warning "should be managed by try-with-resource" is emitted by
Eclipse.
Fix the ones that can be silenced simply by moving the declaration of
the variable into a try-with-resource.
In cases where we explicitly call the close() method, for example in
tests where we are testing specific behavior caused by the close(),
suppress the warning.
Leave the ones that will require more significant refcactoring to fix.
They can be done in separate commits that can be reviewed and tested
in isolation.
Change-Id: I9682cd20fb15167d3c7f9027cecdc82bc50b83c4
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
Enhance ResetCommand to allow disabling reflog update
This will be used by EGit for implementing commit amend in the staging
view (see Idcd1efeeee8b3065bae36e285bfc0af24ab1e88f).
Change-Id: Ice9ebbb1c0c3314c679f4db40cdd3664f61c27c3
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Make sure to overwrite files when "reset --hard" detects conflicts
When performing a "reset --hard" a checkout is done. The pathes are
checked for potential checkout conflicts. But in the end for all
remaining conflicts these files are simply deleted from the working
tree. That's not the right strategy to handle checkout conflicts during
"reset --hard". Instead for every conflict we should simply checkout the
merge commit's content.
This is different from native gits behavior which reports errors when
during a "checkout --hard" a file shows up where a folder was expected.
"warning: unable to unlink d/c.txt: Not a directory"
Why it is like that in native git was asked in
http://permalink.gmane.org/gmane.comp.version-control.git/279482. Unless
it is explained why native git why this error is reported JGit should
overwrite the files.
Bug: 474842
Change-Id: I08e23822a577aaf22120c5137eb169b6bd08447b
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
ResetCommandTest: Use Git member in testHardResetAfterSquashMerge
Use the class member instance of the Git rather than creating
a new one in the test. This makes it consistent with the other
tests in the module.
Change-Id: Ibe822ded76a80b94922e92bbc6f5d90bcc52f8a3
Signed-off-by: David Pursehouse <david.pursehouse@sonymobile.com>
ResetCommand was not returning the updated ref as a result of the call()
method. Since the ResetCommand is always updating the same ref (HEAD)
this should always be the HEAD ref.
Bug: 440750
Change-Id: I7974975c3ab05e68c208384e69cf0692ded6e8db
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Repository: Introduce exactRef and findRef, deprecate getRef
The Repository class provides only one method to look up a ref by
name, getRef. If I request refs/heads/master and that ref does not
exist, getRef will look further in the search path:
ref/refs/heads/master
refs/heads/refs/heads/master
refs/remotes/refs/heads/master
This behavior is counterintuitive, needlessly inexpensive, and usually
not what the caller expects.
Allow callers to specify whether to use the search path by providing
two separate methods:
- exactRef, which looks up a ref when its exact name is known
- findRef, which looks for a ref along the search path
For backward compatibility, keep getRef as a deprecated synonym for
findRef.
This change introduces findRef and exactRef but does not update
callers outside tests to use them yet.
Change-Id: I35375d942baeb3ded15520388f8ebb9c0cc86f8c
Signed-off-by: Jonathan Nieder <jrn@google.com>
ResetCommand threw an NPE if neither mode nor path was defined. Instead
it should default to a mixed reset like native git does.
Change-Id: I455902394f9e7b0c7afae42381f34838f7f2a138
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
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>
Matthias Sohn
René Scheibe
David Pursehouse
Christian Halstrick
David Pursehouse
Jonathan Nieder
Robin Stocker
Robin Rosenberg
Tomasz Zarna
Kevin Sawicki
Dariusz Luksza
Bernard Leach
Chris Aniszczyk