Improve robustness of direct mode merge, avoiding a crash if the index file is missing.

I couldn't find a good way to make an *empty* index file (zero byte file
won't do), so I punted and just don't make index.lock when there's no index
yet. This means some other git process could race and write an index file
at the same time as the merge is ongoing, in theory. Only happens in new
repos though.
This commit is contained in:
Joey Hess 2015-09-22 12:59:56 -04:00
parent 84f07eb947
commit dc2f1f09b7
4 changed files with 29 additions and 3 deletions

View file

@ -26,3 +26,5 @@ Also note that the second repository is on a FAT32 usb stick
# End of transcript or log.
"""]]
> [[fixed|done]] --[[Joey]]

View file

@ -0,0 +1,19 @@
[[!comment format=mdwn
username="joey"
subject="""comment 3"""
date="2015-09-22T16:25:15Z"
content="""
Ok, that seems clear enough, and there's only 1 place where git-annex
copies .git/index; in `mergeDirect`. Indeed, if .git/index doesn't exist
yet when that is called, it'll crash. And, a freshly created git repo
starts off without a .git/index until changes start to be staged.
However, I can't reproduce the crash with a current version of git-annex,
and this bug report is about a version nearly a year old now. AFAICS,
the sync (or the assistant) will make a commit before merging, and that
commit results in the index file being created, as a side effect.
Also, I can't see anything that VFAT could have to do with this.
Hmm, I did manage to reproduce the crash using the new --no-commit flag to
git-annex sync. Will fix on that basis.
"""]]