mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

support modifying and running git add on an unlocked file that used an URL key

Browse source 
Avoids the smudge --clean filter failing because URL keys do not support
genKey. Instead the modified content will be added using the default
backend.

This commit was sponsored by Jochen Bartl on Patreon.
This commit is contained in:
Joey Hess 2021-01-25 17:34:58 -04:00
parent 34a535ebea
commit 47338bf270
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
3 changed files with 19 additions and 45 deletions
Download patch file Download diff file Expand all files Collapse all files

34
doc/bugs/smudge_clean_can_fail_on_URL_key.mdwn
View file

@ -18,36 +18,4 @@ modify it, and run `git add`.
Since the smudge filter fails, git stages the file content into git.
I investigated fixes for this, but nothing seemed to handle both cases
well.
One approach is for Command.Smudge to check if genKey is supported
for the old backend, and if not, use the default backend. This handles the
git add case, but in the adjust case, the adjusted branch has a file using
the default backend, which is a change the user didn't intend, and which
will propagate back to the master branch.
Or, Command.Smudge could check isUnmodified, and if not, emit the old
key. But the URL backend can't verify content, so then a modification to
the file that keeps the size the same, when `git add` is used, will
generate the same old URL key, which invites data loss.
Maybe have smudge use the default backend, and when adjusting a branch,
don't unlock files that don't support genKey?
> This seems least bad, although maybe it will be a problem for
> some users particularly on crippled filesystems. I think anyone who
> sees a behavior change due to this would have been doing something
> that would put them at risk for experiencing the bug above, which
> is worse because it can stage large files into git.. I have an
> implementation of this in the noadjustURL branch.
Or is there some way to make git-annex adjust checkout the branch
w/o smudging the files? I don't understand why it does. git-annex
unlock of an URL key file does not have the problem, so it seems it
should be possible for checking out the adjusted branch to also avoid the
problem.
(Or well, could just remove addurl --fast and so remove URL keys...
Keys that don't support genKey and also don't support verification
being the root of the problem.)
> [[fixed|done]] --[[Joey]]