bugs/unannex: Cannot proceed with uncommitted changes staged in the indexgit-annexhttp://git-annex.branchable.com/bugs/unannex__58___Cannot_proceed_with_uncommitted_changes_staged_in_the_index/git-annexikiwiki2017-07-24T08:06:55Zcomment 1http://git-annex.branchable.com/bugs/unannex__58___Cannot_proceed_with_uncommitted_changes_staged_in_the_index/comment_1_1c0cad1076d5d4d908b8297e7c13ea33/joey2016-07-12T17:12:54Z2016-07-12T16:23:51Z
<p>In v5 mode, there is a complex interaction between unannex and the
pre-commit hook. An unannexed file looks quite a lot like an unlocked file,
so the pre-commit hook is prone to want to lock it, and so add it back to
the annex as an annexed file.</p>
<p>To avoid that problem, unannex needs to commit the unannexing of the
files.</p>
<p>However, if you have other staged changes, they'll also be included in that
commit. Which would be a bug if it were allowed to happen. This is why
it checks for a clean index first.</p>
<p>It would be possible to improve the behavior by explicitly committing only
the files that got unannexed, rather than all staged changes. Why didn't I
do that?</p>
<p>Well, <code>git commit $file</code> stages any changes to the file's content before
committing. When the file has been unannexed, this stages the entire large
file content into git, and adds it back. Not the desired behavior!</p>
<p>Git in fact has no interface to make it commit only staged changes to
only specific files. I can't get there from here. It would certianly
be nice if git got the ability to do that, if someone wants a project to
improve git.</p>
<p>It's very nice that v6 mode avoids this problem entirely!</p>
comment 2http://git-annex.branchable.com/bugs/unannex__58___Cannot_proceed_with_uncommitted_changes_staged_in_the_index/comment_2_4609f9a1545b08e08021bf786561f5e5/tom.prince2017-07-21T18:22:28Z2017-07-21T18:22:28Z
As far as I can tell, from looking at the code, the pre-commit hook only looks at files in the index. Thus, if unannexing an uncommited file removed it from the index, the pre-commit will do the right thing. This would be nice to have, at least for the case where the files have never been committed.
User expectations and what git annex unannex does.http://git-annex.branchable.com/bugs/unannex__58___Cannot_proceed_with_uncommitted_changes_staged_in_the_index/comment_3_6c99a97d56b1a3b12092c15fafcf8761/stephane-gourichon-lpad2017-07-24T08:06:55Z2017-07-24T08:06:55Z
<h1>Where we are</h1>
<p>@joey thank you for these explanations, more detailed than when I reported the same problem 8 months ago commenting https://git-annex.branchable.com/git-annex-unannex/ (@tom.prince had already written this page but I did not find it).</p>
<p>Yet all this happens in a git world, where private history can be rewritten, so <em>there must be a simpler way</em>.</p>
<h1>What people expect from "undo accidental add command"</h1>
<p>@tom.prince thanks for explaining what you expected <code>unannex</code> to do. Looks like I expected exactly the same behavior.</p>
<p>IMHO current behavior of <code>git annex unannex</code> does not match what people expect of "undo accidental add command".</p>
<h1>What current <code>git-annex unannex</code> actually does</h1>
<p>If behavior does not match words, perhaps behavior is interesting but should be matched with different words?</p>
<p>Looking at what <code>git-annex unannex</code>, here are the words that came to mind:</p>
<blockquote><p>git-annex unannex - turn a path which points to annexed content into a plain file that is store in regular git.</p></blockquote>
<p>Notice that:</p>
<ul>
<li><code>git-annex</code> retains history</li>
<li>other paths may still refer to the same content, so the annex may still contain a copy of the same data. Else it becomes unused content subject to <code>git-annex dropunused</code>.</li>
</ul>
<p>Thank you for your attention.</p>