4

The following pastebin is a repo with one file with one, two, three, four, five typed on each line.

Each line was commited separately into git:

http://pastebin.ca/raw/2136179

I then tried to delete the line two with the command git revert <commmit which creates two>

And get:

error: could not revert b4e0a66... second
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'

There should be no conflict for something this simple? Or am I doing it wrong/got the wrong command?

The merge details don't seem to make sense either:

one
<<<<<<< HEAD
two
three
four
five
=======
>>>>>>> parent of b4e0a66... second

Isn't that saying delete everything but one? I was expecting only two to be affected...

git 1.7.10

sabgenton
  • 1,823
  • 1
  • 12
  • 20

2 Answers2

2

I tried to repeat your steps and found the same problem. It seems that you can revert only the most recent commits. In my repository:

$ git log --oneline
9a25594 five
f8f1ec4 four
3c75345 three
e6cd245 two
8349ccc one
d2f16c4 for stkofl  <<==== ignore this one

$ git revert 9a25 --no-edit
Finished one revert.
[master 82bbc79] Revert "five"
 1 files changed, 0 insertions(+), 1 deletions(-)
$ git reset --hard
HEAD is now at 82bbc79 Revert "five"

Reverting any set of commits that is not a set of consecutive commits including HEAD (the most recent commit) seems to be disallowed.

Of course, you can do this:

    $ git show e6cd |patch -R
    patching file file
    Hunk #1 succeeded at 1 with fuzz 1.

and then commit the result.

tripleee
  • 175,061
  • 34
  • 275
  • 318
Mohan Nayaka
  • 31
  • 2
  • You most certainly can revert commits that are not recent. It just doesn't work in this case. – svick Apr 15 '12 at 15:14
  • 1
    Yuck but well stated! If the latest version of git has a --strategy= fix I would love to know if not I will give you the tick for the pipe to `patch -R`, eventually. – sabgenton Apr 16 '12 at 01:59
  • I needed to use `patch -R -p1` in order to get things to (almost) work. The output from `git show` has a diff between `a/file` and `b/file` which cannot apply without the addition of the `-p1` option. Ultimately, things have changed so much that a lot of the changes ended up being rejected by `patch` anyway in my case, but I can sort them out. – tripleee May 22 '14 at 05:21
1

Changes are saved as context diffs... if you look at the diff for third, you'll notice that it is applied in terms of the line containing two, which means it is dependent on the commit that introduced two. Likewise each successive commit is then dependent on the immediately preceding commit, which is why it wants to remove all the commits following the one that introduced two (since they all ultimately depend on that commit). This is why you shouldn't rely on being able to revert commits in the general case, but only immediately after committing them.

geekosaur
  • 59,309
  • 11
  • 123
  • 114
  • Ah ok, are you saying that I should only use this command where I would probably just do git reset --hard HEAD^ ? – sabgenton Apr 15 '12 at 06:32
  • Well it would still be useful if you had pushed but not as useful as I'd hoped.. (I'm am less likely to have stuffed up on just one push) – sabgenton Apr 15 '12 at 06:33
  • I tried the manual way to do 'hg backout' described here http://mercurial.selenic.com/wiki/Backout (replacing revert with checkout .) and the same thing happen! – sabgenton Apr 15 '12 at 10:32
  • http://stackoverflow.com/a/3207170 seems to guess the merge strategy resolve will fix things but I don't have it with my version of revert I tried it with the merge command running the above comment but no luck I'll have to come back later when I get hold of a newer version. – sabgenton Apr 15 '12 at 13:23
  • It sounds like you understand what's going on far more than me. Interestingly the latest version of Mercurial `hg backout` works out of the box with no merge strategy flag changing (but in there older versions it fails like git 1.7.10) – sabgenton Apr 15 '12 at 13:27