hmm... seems like undo respects unstaged changes after all, ohwell
This commit is contained in:
parent
528e3323c5
commit
0e4612a547
1 changed files with 1 additions and 10 deletions
|
@ -110,16 +110,7 @@ There is also the `undo` command to do the equivalent of the above revert in a s
|
|||
|
||||
git annex undo file
|
||||
|
||||
to revert the last committed change to `file` in direct mode. Note that if the file is marked as modified and *not* committed, this may not do what you expect and may very well revert the *previous* change to that file! So first check if the file is actually committed:
|
||||
|
||||
$ git annex status file # check if the file was committed
|
||||
M file
|
||||
$ # uh-oh, not running the assistant or the file wasn't added!
|
||||
$ git annex add file # make sure we commit the working copy so we revert *that*
|
||||
$ git annex status file # look how that change is now committed
|
||||
$ git annex undo file # okay, good to go, now we're reverting to the previous version
|
||||
|
||||
If you would have skipped that `git annex add`, above, you would have revert to the version *before* the version that was before the modified version! In other words, two versions before! Note that you can use the `--depth` flag to revert even earlier versions of the file.
|
||||
to revert the last change to `file`. Note that you can use the `--depth` flag to revert earlier versions of the file.
|
||||
|
||||
## forcing git to use the work tree in direct mode
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue