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

done with adjusted view branches!

Browse source 
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
Download patch file Download diff file Expand all files Collapse all files

5
CHANGELOG
View file

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

7
doc/todo/unify_adjust_with_view.mdwn
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. with an adjusted branch checked out.
Prohibit entering a view branch with the --hide-missing adjustment. 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 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 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 It seems it would make sense for an adjusted view branch to
have a name like `"views/adjusted/master(unlocked)(author=_)"` if 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 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 do the usual adjusted branch propagation at all. Because the only change
that gets synced from a view branch is changes to metadata. that gets synced from a view branch is changes to metadata.
> [[done]]! --[[Joey]]