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

Merge branch 'master' into proxy

Browse source
This commit is contained in:
Joey Hess 2024-06-10 14:26:18 -04:00
commit 649b87bedd
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
16 changed files with 159 additions and 58 deletions
Download patch file Download diff file Expand all files Collapse all files

1
doc/bugs/annex_merge__breaks_git_repository__33__.mdwn
View file

@ -53,3 +53,4 @@ there are good and there are some bad days ;)
[[!meta author=yoh]]
[[!tag projects/openneuro]]
> [[fixed|done]] --[[Joey]]

30
doc/bugs/annex_merge__breaks_git_repository__33__/comment_10_df68709f0b9cdc265bdf37056af4edcc._comment Normal file
View file

@ -0,0 +1,30 @@
[[!comment format=mdwn
username="joey"
subject="""comment 10"""
date="2024-06-10T14:36:37Z"
content="""
While I don't think this affects the ds002144 repository
(because the repository with the missing tree is dead), here's what happens
if the export.log's tree is missing, master has been reset to a previous tree,
which was exported earlier, and in a clone we try to get a file that is present
in both trees from the remote:
get foo (from d...) fatal: bad object f4815823941716de0f0fdf85e8aaba98d024d488
unknown export location
Note that the "bad object" message only appears the first time run.
Afterwards it only says "unknown export location".
Even if the tree object later somehow gets pulled in, it will keep failing,
because the exportdb at this point contains the tree sha and it won't try
to update from it again.
To recover from this situation, the user can make a change to
the tree (eg add a file), and export. It will complain one last time about
the bad object, and then the export.log gets fixed to contain an available
tree. However, any files that were in the missing tree that do not get
overwritten by that export will remain in the remote, without git-annex
knowing about them. If the remote has importtree=yes, importing from it
is another way to recover.
"""]]

15
doc/bugs/annex_merge__breaks_git_repository__33__/comment_8_678151d78d145da6d249184ac212f935._comment Normal file
View file

@ -0,0 +1,15 @@
[[!comment format=mdwn
username="joey"
subject="""comment 8"""
date="2024-06-07T17:59:43Z"
content="""
Fixed performTransitionsLocked to create the new git-annex branch
atomically.
Found another way this could happen, interrupting `git-annex export` after
it writes export.log but before it grafts the tree into the git-annex
branch. Fixed that one too.
So hopefully this won't happen to any more repositories with these fixes.
Still leaves the question of how to recover from the problem.
"""]]

16
doc/bugs/annex_merge__breaks_git_repository__33__/comment_9_67dfc2b1444bd345f911ed779cb98bcc._comment Normal file
View file

@ -0,0 +1,16 @@
[[!comment format=mdwn
username="joey"
subject="""comment 9"""
date="2024-06-07T20:25:27Z"
content="""
Note that at least in the case of ds002144, its git-annex branch does not
contain grafts of the missing trees. The grafts only get created in the
clone when dealing with a transition.
So, it seems that to recover from the problem, at least in the case of this
repository, it will be sufficient for git-annex to avoid regrafting trees
if the object is missing.
Done that, and so I suppose this bug can be closed. I'd be more satified if
I knew how this repository was produced though.
"""]]