mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

comment

Browse source
This commit is contained in:
Joey Hess 2023-02-08 12:41:54 -04:00
parent 21e8d201f3
commit dcaea65e39
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 27 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

27
doc/todo/Metadata_changes_are_not_reflected_in_a_view/comment_3_39d7b5588595067332909c53b232c413._comment Normal file
View file

@ -0,0 +1,27 @@
[[!comment format=mdwn
username="joey"
subject="""comment 3"""
date="2023-02-08T16:29:36Z"
content="""
Another time it would make sense to update the view is after git pull from
elsewhere, which could change the metadata, or change the files present in
the parent branch. I think it would make sense for `git-annex sync` run in
a view to update the view after pulling.
Updating the branch after `git-annex metadata` is run locally is of course
also possible. There is a similarity to updating an adjusted branch after
get/drop. Which has a config annex.adjustedbranchrefresh to tune how
frequently to update the branch. Or the user could just run
`git-annex sync --no-pull --no-push` themselves.
There is probably a lot of scope for optimisation in updating the view
branch, that might be able to get it reasonably quick.
I have not fully thought through it, but basically diffing from the old
parent branch to the new parent to find files that have changed, and
adding/removing those from the view. And also diffing from the old
git-annex branch tree to the new one to get changes to metadata logs,
parsing those and using changes to metadata to also move/delete/add
files to the view branch.
But it would be ok to start with a simple, slow implementation.
"""]]