From ef9534ad106afa4bae0770ac01f202b614548a3b Mon Sep 17 00:00:00 2001 From: mitzip Date: Wed, 27 May 2015 21:48:13 +0000 Subject: [PATCH] --- .../Proper_usage_of_git_annex_proxy_to_mimc_undo_--depth.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/forum/Proper_usage_of_git_annex_proxy_to_mimc_undo_--depth.mdwn b/doc/forum/Proper_usage_of_git_annex_proxy_to_mimc_undo_--depth.mdwn index fd2927c5d6..1112932bed 100644 --- a/doc/forum/Proper_usage_of_git_annex_proxy_to_mimc_undo_--depth.mdwn +++ b/doc/forum/Proper_usage_of_git_annex_proxy_to_mimc_undo_--depth.mdwn @@ -8,7 +8,7 @@ I saw this in the `git revert` docs and thought that `git annex proxy -- git che What I've found is that your suggestion of `git revert` is nice because it wouldn't create a conflict, as `git checkout` does. -So annex, thorough as it is, creates a `$filename.variant-local.$ext` file after the auto conflict resolution to preserve the original. `git revert` is neater, history wise, because there is no conflict because git knows exactly what's changing and from whence it came, rather than just some new file content showing up from who knows where with `git checkout`. +So annex, thorough as it is, creates a `$filename.variant-local.$ext` file after the auto conflict resolution to preserve the original. `git revert` is neater, history wise, because there is no conflict as git knows exactly what's changing and from whence it came, rather than just some new file content showing up from who knows where with `git checkout`. The issue it seems is that git revert works on a commit basis, while git checkout can operate on files. If I'm correct in this it would be good to know if annex uses one commit per file, for sure, every time? If this is the case, there would be no problem using the better in most every other way `git revert`.