change v6 git-annex add of staged unmodified unlocked file

v6: When a file is unlocked but has not been modified, and the unlocking is
only staged, git-annex add did not lock it. Now it will, for consistency
with how modified files are handled and with v5.

Note the removal of the sameInodeCache check. Otherwise it would see
that the unmodified file is unmodified and stop there. That check seems to have
been copied from the direct mode branch. But, direct mode had a specific
reason to check for unmodified content, that does not apply to v6.

The second pass means there is potential for a race, eg the unlocked
file could be modified in between the first and second passes.
No problem with that, since both passes do the same thing.

This commit was sponsored by Jake Vosloo on Patreon.
This commit is contained in:
Joey Hess 2018-09-12 13:53:03 -04:00
parent 5e0c7bf81d
commit 2743224658
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
5 changed files with 49 additions and 8 deletions

View file

@ -38,3 +38,5 @@ special handling for the V6 behavior.
upgrade supported from repository versions: 0 1 2 3 4 5
on Debian Stretch, built from source with `stack build`
> [[fixed|done]] --[[Joey]]

View file

@ -0,0 +1,23 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2018-09-12T16:29:55Z"
content="""
In fact, `git annex add` does not process the v6 unlocked file at all
since it only looks for unstaged changes to files and the unlocked file's
type change has been staged already.
In v5 mode there is a separate pass to add unlocked files, which is
necessary since they have to be converted back to locked files before they
can be committed.
It would need a separate pass in v6 too, since the main pass looks only
at unstaged modifications and git can't be queried for staged modifications
at the same time as unstaged.
Hmm, this would though mean that `git annex add` would now be changing
what's staged. It has never done that before; it's only staged new changes.
Not convinced by that argument, but something to keep in mind.
I'm feeling this is ok to change, and the patch is not difficult.
"""]]