### Please describe the problem.

If you `git annex edit FILE`, an already-committed file, then do `git annex sync`, FILE will be added to .git/objects, but can be cleaned up with `git prune`. An annoyance, but not a huge problem.

> This is why you're recommended to use `git add` after you're done
> changing unlocked files. This avoids the git commit staging the file
> in the index, even though the pre-commit hook fixes that up. It does
> indeed leave the file contents in .git/objects, although with no refs
> pointing to it, `git prune` will delete it sooner or later. --[[Joey]]

If, on the other hand, you do git annex add, then edit, then sync, it will actually be committed to the git repository. Fixing that is a lot less trivial than `git prune`.

> This is indeed a problem..

### What steps will reproduce the problem?

    anthony@Watt:/tmp/test$ du -sh .git/objects/
    24K     .git/objects/
    anthony@Watt:/tmp/test$ dd if=/dev/urandom bs=$[1024*1024] count=100 of=100mb-3
    100+0 records in
    100+0 records out
    104857600 bytes (105 MB) copied, 6.08718 s, 17.2 MB/s
    anthony@Watt:/tmp/test$ git annex add 100mb-3
    add 100mb-3 ok
    (Recording state in git...)
    anthony@Watt:/tmp/test$ git annex edit 100mb-3
    unlock 100mb-3 (copying...) ok
    anthony@Watt:/tmp/test$ git annex sync
    commit  ok
    anthony@Watt:/tmp/test [$?=130]$ git prune
    anthony@Watt:/tmp/test$ du -sh .git/objects/
    101M    .git/objects/
    anthony@Watt:/tmp/test$ ls -l 100mb-3 
    -rw-r--r-- 1 anthony anthony 104857600 Jan  1 13:41 100mb-3


### What version of git-annex are you using? On what operating system?

5.20141125 on Debian testing/unstable

> Analysis: This only happens when a file is added and then unlocked
> without first being committed.
> 
> In this situation, the file has a typechange between the index and
> the working tree. However, by the time the pre-commit hook gets
> run, git commit has already staged the unlocked file content into the
> index. So, there is nolonger a typechange between the index and the work
> tree. And, since the file is new, there is no typechange between the
> index and last commit either. The latter is what the pre-commit hook
> looks for.
> 
> Conclusion: The pre-commit hook cannot possibly detect this situation.
> Instead, it seems the only way to block the problem is to prevent
> unlocking a file that does not have any git history.
> 
> And I've [[done]] that now. --[[Joey]]