git annex adjust and git annex view (et all) both derive a branch from the main branch and enter it. They have different capabilies. It would be useful to be able to compose them. For example, to enter a view based on metadata that also has all files unlocked. --Joey

Now that git-annex sync supports view branches, this is more apparently a problem.

It's possible to check out a view branch, and then git-annex adjust --unlock, and the result will be a view branch with unlocked files. But then git-annex sync doesn't work; it neither syncs back to the parent view branch, nor all the way back to the parent master branch. It seems that git-annex gets confused about what this strangely named branch is ("adjusted/views/master(author=_)(unlocked)"), and does not treat it as either kind of branch.

Conversely, first doing git-annex adjust --unlock, followed by checking out a view branch from there results in a view branch that does not have the files unlocked. ("views/adjusted/master(unlocked)(author=_)"). And syncing fails from there:

fatal: not a valid object name: 'adjusted/master'

git-annex: failed to update refs/heads/synced/adjusted/master

There's also probably a fair amount of overlap in their implementations.

I now think not really so much. View branches are constructed using a temporary index file (and need it), while adjusted branches are able to stream to git mktree.

The main overlap is that there is a basis branch that gets transformed to a new branch. And a way for git-annex sync to update the branch when the basis branch (or other info) changes.

Consider a branch that is a view branch, where git-annex adjust --hide-missing was then run. After git-annex drop, updating the adjusted branch should cause the dropped file to be removed. But removing a file from a view branch means removing that metadata from the object.

So, it seems that composing that kind of adjusted branch with view branches is unlikely to work.

Considering all the the above, I think this would be a good plan:

Implemented adjusted view branches. Not views of adjusted branches. Although running git-annex adjust with a view branch checked out could 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 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. 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