`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]]