9fcaf27cba
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.
73 lines
3.1 KiB
Markdown
73 lines
3.1 KiB
Markdown
`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]]
|