unannex: Refuse to unannex when repo is too new to have a HEAD

In this case there must be staged changes in the index (if there is
anything to unannex), and the unannex code path needs to run with a clean
index.
This commit is contained in:
Joey Hess 2015-02-25 13:59:23 -04:00
parent 80aa7e3571
commit 8a3e2b302a
4 changed files with 45 additions and 5 deletions

View file

@ -28,3 +28,4 @@ git-annex: Cannot proceed with uncommitted changes staged in the index. Recommen
### What version of git-annex are you using? On what operating system?
The issue occurs with last version of git-annex, available at the time of this post (2015-02-19 16:20). I could reproduce the issue in all other versions of git-annex I tried (not many though). I am using Linux, Ubuntu 12.04 amd64.
> [[done]]; added check for repository too new to have a HEAD. --[[Joey]]

View file

@ -0,0 +1,32 @@
[[!comment format=mdwn
username="joey"
subject="""comment 1"""
date="2015-02-25T17:45:50Z"
content="""
Git provides ample facilities to remove any commits that you don't like
from your repository's history. Eg, `git reset HEAD^^`
This check for a clean index was added in [[!commit 7dc680415480fbbadc5dfd37f1ce72084fb1887d]]
which made unannex not make 1 commit per file it unannexed. That was a
massive improvement in speed and number of commits.
In order for unannex to make just 1 commit at the end, instead of 1 per
file, it has to stage its changes in the index. Since it then needs to
commit the index at the end, we have one reason for it to require the index
not have staged changes, since those stages changes would get included in
the unannex commit.
I suspect I had a second reason in mind when making that change.
The unannex commit has to be run with the pre-commit hook disabled
for complicated reasons. Involving other changes that are not unannex
changes in that commit would thus defeat the fixups that the pre-commit
hook normally does to such changes. This would at least prevent annexed
symlink path fixups from happening, and it might result in whole unlocked
files getting their full contents unexpectedly committed to git.
There is no inconsistency between new and existing directories.
The difference is between repositories with a HEAD and repositories too
new to have one. Maybe it's a bug that unannex doesn't refuse to run
in a repostory too new to have a HEAD, since it cannot tell if there are
other staged changes with no HEAD to diff against.
"""]]