summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorGravatar mitzip <mitzip@web>2015-05-27 21:36:08 +0000
committerGravatar admin <admin@branchable.com>2015-05-27 21:36:08 +0000
commitd8cc232487f9ecdc6493f49738e6136f4877a57d (patch)
tree914e806d2a885c3b802c8758d6cb7cc58d2f0752
parentbe0574f608158935762398acac5ef837778c41c0 (diff)
removed
-rw-r--r--doc/direct_mode/comment_19_b851fbb0a86639770e6432c6431480a3._comment15
1 files changed, 0 insertions, 15 deletions
diff --git a/doc/direct_mode/comment_19_b851fbb0a86639770e6432c6431480a3._comment b/doc/direct_mode/comment_19_b851fbb0a86639770e6432c6431480a3._comment
deleted file mode 100644
index 4e0878b76..000000000
--- a/doc/direct_mode/comment_19_b851fbb0a86639770e6432c6431480a3._comment
+++ /dev/null
@@ -1,15 +0,0 @@
-[[!comment format=mdwn
- username="mitzip"
- subject="proper usage of git annex proxy to mimic undo --depth"
- date="2015-05-27T21:33:42Z"
- content="""
-Thanks for correcting that, and thanks for the git-revert suggestion!
-
-I saw this in the `git revert` docs and thought that `git checkout annex/direct/master~$depth` might best suit my needs of restoring a previous version of a file. (I liked the idea of presenting the user with a depth rather than a hash.)
-
->Note: git revert is used to record some new commits to reverse the effect of some earlier commits (often only a faulty one). If you want to throw away all uncommitted changes in your working directory, you should see git-reset[1], particularly the --hard option. If you want to extract specific files as they were in another commit, you should see git-checkout[1], specifically the git checkout -- syntax. Take care with these alternatives as both will discard uncommitted changes in your working directory.
-
-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 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 when, 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, does annex use 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`.
-
-Though, I'm still not clear how to use the \"depth\" referencing with `git revert` rather than hashes.
-"""]]