Remove fixup code for bad bare repositories created by versions 5.20131118 through 5.20131127. That fixup code would accidentially fire when --git-dir was incorrectly pointed at the working tree of a git-annex repository, resulting in data loss. Closes: #768093
This commit is contained in:
parent
deee74ff6d
commit
334f366979
4 changed files with 29 additions and 57 deletions
|
@ -30,3 +30,5 @@ I am running Debian sid.
|
|||
|
||||
# End of transcript or log.
|
||||
"""]]
|
||||
|
||||
> [[fixed|done]] --[[Joey]]
|
||||
|
|
|
@ -0,0 +1,21 @@
|
|||
[[!comment format=mdwn
|
||||
username="joey"
|
||||
subject="""yikes!"""
|
||||
date="2014-11-04T21:47:07Z"
|
||||
content="""
|
||||
I'm very sorry you encountered this bug. I'd like to do anything
|
||||
possible to recover your repository. While investigating it, it looks
|
||||
like, when the repository is not a fresh and empty repo, it doesn't
|
||||
actually get completely nuked. Instead, the contents of the .git directory,
|
||||
including annexed objects, is left in "removeme". It should be possible to
|
||||
mostly recover from that. I can try to walk you through it if necessary.
|
||||
|
||||
I know exactly what the cause of this bug is. It's a workaround for a bug
|
||||
in some by now quite old versions of git-annex (from last year). That old bug
|
||||
caused a .git/.git directory to be created, and so this workaround looks
|
||||
for $GIT_DIR/.git and does what turn out to be horrible things in this
|
||||
case.
|
||||
|
||||
So, I have immediately removed that old workaround, so noone else will
|
||||
encounter this.
|
||||
"""]]
|
Loading…
Add table
Add a link
Reference in a new issue