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

reorg section and expand

Browse source 
conflict detection at import time is not detected, but I think it's ok
given this reasoning
This commit is contained in:
Joey Hess 2019-04-09 12:59:14 -04:00
parent 4211281336
commit b51eceb326
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 33 additions and 20 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

53
doc/design/importing_trees_from_special_remotes.mdwn
View file

@ -50,26 +50,6 @@ to expect there to be one, and if it later turns out that the last exported
commit needs to be available across clones, store it in the git-annex commit needs to be available across clones, store it in the git-annex
branch then. branch then.
## export conflict resolution
What if the export log indicates an unresolved export conflict,
and the user tries to import from the special remote?
Well, two trees got exported to the remote independently. The content of
the remote is not known to export code when there's a conflict, but import
will resolve that by getting a list of its contents. Although that may be
an admixture of the two exported trees, and so not necessarily a change the
user will want to merge into master.
One approach is to not allow imports in this situation; require the export
conflict be resolved first. (--force could override if the user just wants
to import whatever ended up on the special remote.)
Another approach, if the commits that contain the trees that were exported
is known, is to do the import and make a commit that uses those commits
as its parents. Which nicely indicates to git that there was a conflict and
it got "resolved".
## command line interface ## command line interface
`git annex import master --from foo` will import a tree from the remote `git annex import master --from foo` will import a tree from the remote
@ -306,3 +286,36 @@ update the export log to say that the remote has that treeish exported
to it. A conflict between two export log entries will be handled as to it. A conflict between two export log entries will be handled as
usual, with the user being prompted to re-export the tree they want usual, with the user being prompted to re-export the tree they want
to be on the remote. (May need to reword that prompt.) to be on the remote. (May need to reword that prompt.)
----
What if the export log indicates an unresolved export conflict,
and the user tries to import from the special remote?
Well, two trees got exported to the remote independently. The content of
the remote is not known to export code when there's a conflict, but import
will resolve that by getting a list of its contents. Although that may be
an admixture of the two exported trees, and so not necessarily a change the
user will want to merge into master.
One approach is to not allow imports in this situation; require the export
conflict be resolved first. (--force could override if the user just wants
to import whatever ended up on the special remote.)
Another approach, if the commits that contain the trees that were exported
is known, is to do the import and make a commit that uses those commits
as its parents. Which nicely indicates to git that there was a conflict and
it got "resolved".
However, note that there can be an export conflict that occurred on another
clone, and that the local repo does not know about yet (git-annex branch
not synced). Importing will then import whatever the current state of the
export conflict is. The export conflict will eventually be caught at export
time, and the user can resolve it then. Since this is unavoidable, the two
approaches above don't seem worth bothering with.
Also, if an export is running at the same time as an import
(presumably on two different clones), part of the
changes made by the export will be imported and part not. Again this will
lead to an export conflict being recorded and the user will have to sort it
out later at export time.