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.

CHANGELOG

@@ -6,6 +6,7 @@ git-annex (7.20190913) UNRELEASED; urgency=medium
   * git-lfs: Only do endpoint discovery once when concurrency is enabled.
   * Test: Use more robust directory removal when built with directory-1.2.7.
   * Close sqlite databases more robustly.
+  * adjust --lock: This enters an adjusted branch where files are locked.
 
  -- Joey Hess <id@joeyh.name>  Thu, 19 Sep 2019 11:11:19 -0400
 

Command/Adjust.hs

@@ -26,6 +26,10 @@ linkAdjustmentParser =
 		( long "unlock"
 		<> help "unlock annexed files"
 		)
+	<|> flag' LockAdjustment
+		( long "lock"
+		<> help "lock annexed files"
+		)
 	<|> flag' FixAdjustment
 		( long "fix"
 		<> help "fix symlinks to annnexed files"

Types/AdjustedBranch.hs

@@ -39,7 +39,8 @@ instance ReversableAdjustment Adjustment where
 
 instance ReversableAdjustment LinkAdjustment where
 	reverseAdjustment UnlockAdjustment = LockAdjustment
-	reverseAdjustment LockAdjustment = UnlockAdjustment
+	-- Keep the file locked intentionally when reversing LockAdjustment.
+	reverseAdjustment LockAdjustment = LockAdjustment
 	reverseAdjustment FixAdjustment = UnFixAdjustment
 	reverseAdjustment UnFixAdjustment = FixAdjustment
 

doc/forum/Preserving_the_v5_experience/comment_4_f5f898e0c8fd598419c52b10c37859de._comment

@@ -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.
+"""]]

doc/git-annex-adjust.mdwn

@@ -4,7 +4,7 @@ git-annex adjust - enter an adjusted branch
 
 # SYNOPSIS
 
-git annex adjust `--unlock|--fix|--hide-missing [--unlock|--fix]`
+git annex adjust `--unlock|--lock|--fix|--hide-missing [--unlock|--lock|--fix]`
 
 # DESCRIPTION
 
@@ -49,6 +49,20 @@ back to the original branch.
   disk space, any modification made to a file will cause the old version of the
   file to be lost from the local repository. So, enable annex.thin with care.
 
+  When in an adjusted unlocked branch, `git annex add` will add files
+  unlocked instead of the default behavior of adding them locked.
+
+* `--lock`
+
+  Lock all annexed file in the adjusted branch. This may be preferred
+  by those who like seeing broken symlinks when the content of an
+  annexed file is not present.
+
+  When in an adjusted locked branch, `git annex add` will add files locked,
+  as usual. However, `git add` (and `git commit -a` etc) still add files
+  unlocked. This is because it's not possible for those git commands to
+  add files locked.
+
 * `--fix`
 
   Fix the symlinks to annexed files to point to the local git annex
@@ -74,7 +88,7 @@ back to the original branch.
   still operate on them, and can be used to download missing
   files from remotes.
 
-  This option can be combined with --unlock or --fix.
+  This option can be combined with --unlock, --lock, or --fix.
 
 # SEE ALSO
 

doc/todo/auto-lock_files_after_one_edit/comment_2_4a6274dd1da7746a5be673ffb0c5d520._comment

@@ -0,0 +1,11 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 2"""
+ date="2019-09-27T17:06:29Z"
+ content="""
+I think it should be possible for a pre-commit hook to do this.
+
+There are some subtleties to a pre-commit hook changing what's going to be
+committed, which I was happy to jettison when removing the v5 support. But
+it should be able to work at least as well as it did in v5.
+"""]]