fix export subtree reversion

Fix reversion in last release that caused wrong tree to be written to
remote tracking branch after an export of a subtree.

The invariant "commitsha should have the treesha as its tree"
was not met due to a bug. Guarantee it's met by catting the commitsha
to find its actual tree. A little bit slower, but this is not run often.
This commit is contained in:
Joey Hess 2019-05-06 13:56:39 -04:00
parent 0533fde73c
commit bf7ecd6892
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
6 changed files with 42 additions and 9 deletions

View file

@ -49,3 +49,4 @@ ls
### Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
git-annex does a great job in managing my distributed backups. Thanks!
> [[fixed|done]] --[[Joey]]

View file

@ -0,0 +1,22 @@
[[!comment format=mdwn
username="joey"
subject="""comment 2"""
date="2019-05-06T16:47:49Z"
content="""
It's not limited to git-annex sync, running import followed by merge and
then export shows the same behavior on the 3rd run. Without the export step,
the bug doesn't happen.
The problem actually is in the second pass, the import is ok, but then the
export sets the remote tracking branch to only contain the subdirectory.
Then in the third pass that bad basis is used by the import (which does
nothing) and gets merged.
Why does only the second export trigger the bug, not the first?
Has to do with makeRemoteTrackingBranchMergeCommit and the shape of the
commit history.
Indeed, 7.20190322 doesn't have this bug, it was introduced in
the newest release which added makeRemoteTrackingBranchMergeCommit.
The export code accidentially passed a tree to that.
"""]]