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:
parent
9f27d03945
commit
090898a138
6 changed files with 54 additions and 3 deletions
|
@ -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.
|
||||
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue