adjust --lock: This enters an adjusted branch where files are locked.

Straightforward, except for the issue of how to reverse LockAdjustment.

With --unlock, a commit that modifies/adds unlocked files gets reverse
adjusted to use locked files. That's fairly reasonable, I think.

But reversing --lock by unlocking all modified files feels wrong. Maybe
that's just because repositories typically seem to still have mostly
locked files in them (unless one is in an adjusted unlocked branch of
course!)

It may be that eventually how to reverse both will need to be configurable,
I don't know.
This commit is contained in:
Joey Hess 2019-09-27 14:23:25 -04:00
parent 9f27d03945
commit 090898a138
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
6 changed files with 54 additions and 3 deletions

View file

@ -0,0 +1,20 @@
[[!comment format=mdwn
username="joey"
subject="""comment 4"""
date="2019-09-27T17:01:28Z"
content="""
Setting annex.largefiles=nothing also makes `git annex add` add all files
to git, which I think is not what you were intending it to do.
> When `neverlock` is active and `git add` is run on a largefile, it could reject adding the file,
Git's interface does not allow me to do that. The clean filter can't
prevent a file from being added; even if it exits nonzero git will just go
ahead and add the file content.
I've implemented `git annex adjust --lock`. It doesn't fully prevent
other commands from making unlocked files. Any change to `git add`
behavior faces the problems I discuss in [[lets_discuss_git_add_behavior]].
And `git annex unlock` can still be used. So
[[todo/auto-lock_files_after_one_edit]] would be a nice complement to this.
"""]]