close bug as dup and update todo item with implementation plan

doc/bugs/view_branch_on_top_of_adjusted_branch_doesn__39__t_sync.mdwn

@@ -145,3 +145,5 @@ Git Annex is great. I use it several times a week with my multigigabyte backups,
 Big thanks, Joey!
 
 [[!meta author=jkniiv]]
+
+> Closing as a dup with a todo item;[[done]] --[[Joey]]

doc/bugs/view_branch_on_top_of_adjusted_branch_doesn__39__t_sync/comment_1_3c0be3ff163aae411f323e3445af94b1._comment

@@ -0,0 +1,10 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2023-02-16T18:17:33Z"
+ content="""
+This is kind of a duplicate of[[todo/unify_adjust_with_view]].
+
+I think it's best to keep it as a todo item, not a bug, since this is a
+desired new behavior.
+"""]]

doc/todo/unify_adjust_with_view.mdwn

@@ -2,8 +2,67 @@
 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.
-
-There's also probably a fair amount of overlap in their implementations.
 --[[Joey]]
 
-[[!tag needsthought]]
+> 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.
+
+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.
+
+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.