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:
parent
0533fde73c
commit
bf7ecd6892
6 changed files with 42 additions and 9 deletions
|
@ -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]]
|
||||
|
|
|
@ -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.
|
||||
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue