proxy: Fix proxy git commit of non-annexed files in direct mode.

* proxy: Fix proxy git commit of non-annexed files in direct mode.
* proxy: If a non-proxied git command, such as git revert
  would normally fail because of unstaged files in the work tree,
  make the proxied command fail the same way.

2 files changed, 35 insertions, 0 deletions

diff --git a/doc/bugs/proxy_--_git_commit__for_a_file_under_git__creates_.variant-local___40__original_file_is_even_get_removed__41__.mdwn b/doc/bugs/proxy_--_git_commit__for_a_file_under_git__creates_.variant-local___40__original_file_is_even_get_removed__41__.mdwn
index b145f6fc0..d104dc91a 100644
--- a/doc/bugs/proxy_--_git_commit__for_a_file_under_git__creates_.variant-local___40__original_file_is_even_get_removed__41__.mdwn
+++ b/doc/bugs/proxy_--_git_commit__for_a_file_under_git__creates_.variant-local___40__original_file_is_even_get_removed__41__.mdwn
@@ -108,3 +108,30 @@ Date:   Tue Jul 28 17:20:29 2015 -0400
 
 # End of transcript or log.
 """]]
+
+> Ok, this is [[fixed|done]].
+> 
+> What was going on is, proxy was reusing mergeDirectCleanup
+> since it's in a similar situation to cleaning up after a direct mode
+> merge. But, a direct mode merge can pull in changes to files that exist
+> in the local work tree (and may or may not be in the index), but are
+> not committed to git locally yet. So, it has to
+> detect those and move them aside (to ".varient-local"). The code to do
+> that is what was failing in this reuse of mergeDirectCleanup.
+> 
+> So, I made that code path not run when using proxy. And for commits,
+> that's good enough. If there's a file in the work tree that's
+> not added to git, then a proxied commit can't affect it, so that code
+> path is not needed in this case.
+> 
+> Come to think, other proxied actions might affect such a file. For
+> example a proxied revert could revert the deletion of a file with the
+> same name, that's in the work tree. In this case, should the proxyed revert
+> fail because there's a file in the work tree that will be overwritten by
+> the revert? Would be good if it did, because git revert will normally fail
+> in this situation.
+> 
+> The only way to make a proxied revert, etc exactly match a
+> non-proxied revert is to arrange for all files that are in the work
+> tree and not checked into git to be present in the temp work tree when
+> the proxied command is run. Which I've now done. --[[Joey]]
diff --git a/doc/git-annex-proxy.mdwn b/doc/git-annex-proxy.mdwn
index 570789cf7..814cc7676 100644
--- a/doc/git-annex-proxy.mdwn
+++ b/doc/git-annex-proxy.mdwn
@@ -31,6 +31,14 @@ stage the changes in the index, and then proxy a commit:
 	git annex add myfile
 	git annex proxy -- git commit myfile -m foo
 
+Note that git annex proxy cannot be usefully used with git commands that
+look at work tree files. For example, it doesn't make sense to proxy "git
+add". This is because the temporary work tree used for proxying doesn't
+contain all the files that are in the real work tree. However, any unstaged
+work tree files are hard linked (or copied) into the temporary work tree,
+so that a command like git revert, that will fail if the change it's
+making overwrites work tree files, will behave the same when proxied.
+
 # SEE ALSO
 
 [[git-annex]](1)