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-09-22 12:36:15 -04:00
parent ef7c867238
commit 5479e2327b
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 30 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

30
doc/bugs/sync_-C_can_export_other_files/comment_1_7a6ab3ee25f0d09df4d7478d26ea2d37._comment Normal file
View file

@ -0,0 +1,30 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2023-09-22T16:26:17Z"
content="""
If files foo and bar have changed, and `git-annex sync -Cfoo` committed
those changes and only exported foo to an exporttree remote, then that
remote would end up with content that does not correspond to any git tree
that the user has constructed.
While it's possible for that to also happen when an export of a tree gets
interrupted in the middle, git-annex recovers from that when the export is
re-run. But here the user might have a workflow where they are only running
that command.
So this would be a new case, and to handle this case it seems it would have
to dummy up a tree representing the changed foo and old bar, in order to
record the export in the git-annex branch and sync it so other repos know
what the content of the export remote is.
So doing that is not feeling like an entirely good idea..
I suppose the alternative would be for `git-annex sync -C` to not send
anything to export remotes. But that also seems potentially confusing.
(Especially as a behavior change.) If I've asked git-annex to sync with an
exporttree remote, shouldn't it do it? Even if it has to do some additional
transferring in the process.
So it may be that the current behavior of sending additional files is better.
"""]]