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

update todo

Browse source
This commit is contained in:
Joey Hess 2019-04-30 16:20:14 -04:00
parent 1503b86a14
commit 83a420dd66
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 6 additions and 47 deletions
Download patch file Download diff file Expand all files Collapse all files

53
doc/todo/import_tree.mdwn
View file

@ -13,55 +13,14 @@ and `git annex sync --content` can be configured to use it.
## remaining todo
* There's a bug in the way the import history is added to the
previous history for the remote. This leads to an ever-growing history
when importing from a versioned S3 remote,
although the head of it does reflect the current state of the remote.
* When generating commits for an imported history, provide a stable author,
committer, and date, so the same commit sha1 is always generated.
This is mostly dealt with, but still doesn't do the right thing
in this situation:
* When the imported history has only one level and matches the last export,
there is no need to generate a merge commit, can just add a new commit on
top of the last export. A simple fast-forward.
1. import from s3
2. merge
3. rename a file
4. export to s3
5. import from s3
6. merge
This results in the whole S3 history being on top of the s3/master
branch, followed by the commit that made the change, which of course
has as its parent most of the S3 history again etc.
The problem is the rename -- in git, that's atomic, so the history
has a single commit. But on S3, that's a delete followed by a put
(or a copy followed by a delete, but in practice, it seems to be delete
and then put). So the tree History from S3 has this extra event in it.
Eg, the git history is
[[newname, foo, bar], [oldname, foo, bar], etc]
while the S3 history is
[[newname, foo, bar], [foo, bar], [oldname, foo, bar], etc]
(Both of the "etc" values are the same.)
While perhaps a heuristic to detect renames could be added to the History
comparison, better would be to generate a merge between the git commit
that was exported to the remote before, and the imported history from the
remote. The merge just needs to have as its tree the current imported
tree.
This way whatever happened on the remote as a consequence of
exports and other changes is preserved in the git history in full.
When creating such a merge, first check if the old value of the remote
tracking branch matches the imported history. If so, nothing to do.
Next, check if the old value of the remote tracking branch is a merge,
and its tree matches the top of the imported history, and one
of its parents matches the full imported history. If so, nothing to do
because that is what we want to generate.
Otherwise, commit the imported history and generate a merge commit.
* Detect more complex fast-forwards from the import? This may be hard..
* S3 buckets can be set up to allow reads and listing by an anonymous user.
That should allow importing from such a bucket, but the S3 remote