done with adjusted view branches!

Well, perhaps it could be documented better, but it's a compositional
feature so users who need it will probably try it and be happy to find
that it works.
This commit is contained in:
Joey Hess 2023-02-27 15:55:31 -04:00
parent 80478cc145
commit 9fcaf27cba
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 8 additions and 4 deletions

View file

@ -1,8 +1,7 @@
git-annex (10.20230228) UNRELEASED; urgency=medium
* Support adjusted view branches. Using git-annex view in an adjusted
branch, or git-annex adjust in a view branch will enter an adjusted
view branch. --unlock and --unlock-present adjustments are supported.
* Using git-annex view in an adjusted branch, or git-annex adjust in a
view branch, will enter an adjusted view branch.
-- Joey Hess <id@joeyh.name> Mon, 27 Feb 2023 12:31:14 -0400

View file

@ -54,6 +54,8 @@ be one way to get into an adjusted view branch. Or running `git-annex view`
with an adjusted branch checked out.
Prohibit entering a view branch with the --hide-missing adjustment.
Update: Actually, I was able to implement support for that adjustment that
seems to work ok in a view branch.
Building the branch seems simple: Construct the view branch like it does
now, using the master branch as the basis. And apply the adjustment to each
@ -61,8 +63,11 @@ file that gets added to it.
It seems it would make sense for an adjusted view branch to
have a name like `"views/adjusted/master(unlocked)(author=_)"` if
that can be parsed unambiguously.
that can be parsed unambiguously. Update: Actually
`"adjusted/views/master(author=_)(unlocked)"` worked better.
When `git-annex sync` runs in an adjusted view branch, it does not need to
do the usual adjusted branch propagation at all. Because the only change
that gets synced from a view branch is changes to metadata.
> [[done]]! --[[Joey]]