From 1c2e5b451911046e88b0e63bf37ca2f2a52b8570 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 16 Feb 2023 14:51:00 -0400 Subject: [PATCH] close bug as dup and update todo item with implementation plan --- ..._of_adjusted_branch_doesn__39__t_sync.mdwn | 2 + ..._3c0be3ff163aae411f323e3445af94b1._comment | 10 +++ doc/todo/unify_adjust_with_view.mdwn | 65 ++++++++++++++++++- 3 files changed, 74 insertions(+), 3 deletions(-) create mode 100644 doc/bugs/view_branch_on_top_of_adjusted_branch_doesn__39__t_sync/comment_1_3c0be3ff163aae411f323e3445af94b1._comment diff --git a/doc/bugs/view_branch_on_top_of_adjusted_branch_doesn__39__t_sync.mdwn b/doc/bugs/view_branch_on_top_of_adjusted_branch_doesn__39__t_sync.mdwn index d8132a3c4d..bda167a806 100644 --- a/doc/bugs/view_branch_on_top_of_adjusted_branch_doesn__39__t_sync.mdwn +++ b/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]] diff --git a/doc/bugs/view_branch_on_top_of_adjusted_branch_doesn__39__t_sync/comment_1_3c0be3ff163aae411f323e3445af94b1._comment b/doc/bugs/view_branch_on_top_of_adjusted_branch_doesn__39__t_sync/comment_1_3c0be3ff163aae411f323e3445af94b1._comment new file mode 100644 index 0000000000..2fdf2b2ea6 --- /dev/null +++ b/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. +"""]] diff --git a/doc/todo/unify_adjust_with_view.mdwn b/doc/todo/unify_adjust_with_view.mdwn index 8cf16161a0..70ad5f11d1 100644 --- a/doc/todo/unify_adjust_with_view.mdwn +++ b/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.