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

break out a todo

Browse source
This commit is contained in:
Joey Hess 2019-05-21 11:10:13 -04:00
parent e51ca437c4
commit 5af9e7f3d0
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 20 additions and 6 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
doc/bugs/surprising_import_tree_merge_result.mdwn
View file

@ -13,9 +13,3 @@ raw/photos/something
This is quite surprising. It seems somehow when it modified the old
tree, it rooted the new at the location the old had been moved to in
master.
----
Also, commit cd55a5be377020b7261c3a737b5e32a01e22f4b8 had no parent, so
git diff --stat shows it as adding every file that was in the tree before
as well as the imported files, which seems wrong at least visually.

20
doc/todo/import_from_special_remote_large_git_log.mdwn Normal file
View file

@ -0,0 +1,20 @@
After import from a special remote and merge, git log --stat shows
a large diff, because every file that got imported from the special
remote is put on a commit with no parent, so the diff shows it as if those
files are newly added.
(Of course when using S3 with versioning, the commit tree does have
parents, but still a root commit with no parent.)
This does not seem avoidable for the initial import, even if the remote was
populated by an earlier export, that starts a new, disconnected history for
reasons explained in the import tree design.
Subsequent imports though could fix it, by setting the parent of the new
import to the previous import.
For versioned imports, it reuses commits from the old imported history,
and adds more commits on top of those, so this is mostly not a problem
there. If the old and new imported histories are disjoint, a commit or
commits will be made with no parent, but that seems acceptable; it's an
edge case and it's replicating the information from the remote.