Revert a single commit in a single file

I tried asking the same question on the "newbie" list some time ago:

http://groups.google.com/group/git-users/browse_thread/thread/d562b4eeac016711

Basically, when I go

.. my expectation was that a new commit would be made reverting the changes from the old commit, but only for specified path/file.

Maybe it's a bit of a corner-case, but still would be nice to have once in a while. What do you think?

On Fri, Feb 25, 2011 at 11:34, Thomas Ferris Nicolaisen <tfnico@gmail.com> wrote:

It would. What you can do in the meantime is:

    git revert <commit>
    git reset
    git add <path>
    git commit ...
    git reset --hard # making sure you didn't have uncommited changes earlier

Ævar Arnfjörð Bjarmason venit, vidit, dixit 25.02.2011 12:17:

Ævar meant to write "git revert --no-commit <commit>" here. (Or there wouldn't be anything to reset and add.)

If you want to revert changes to all files but a few, you can do it the other way round (revert, checkout HEAD^ -- <path>, commit --amend).

Cheers, Michael

The most sensible way to do this seems to be:

 git checkout HEAD~2 file.c

And your index will show file.c modified, as it will have it's content reverted 2 commits.

The behavior of 'revert' is to revert commits, not files, so it's not expected to work if you say 'git revert <commit> <path>'

Cheers, Dario

On Fri, Feb 25, 2011 at 9:37 AM, Michael J Gruber <git@drmicha.warpmail.net> wrote:

Dario Rodriguez venit, vidit, dixit 25.02.2011 13:48:

To do what? I you hadn't top posted we would know what "this" referred to.

It will have its content reset to what it was in HEAD~2. This is very different from reverting the change made in HEAD~2:

It makes perfect sense, it's just not implemented.

Note that you can also

git show <commit> -- <path> | git apply -R

to achieve a partial revert. That might be the easiest route to take.

Michael

[Cutting the bottom copy - what is it good for there?]

Ævar, Michael, thanks for the tips.

Dario: Yes, I understand the reasoning. It's not often a problem, and
when it occurs there are ways to do it. I just thought I'd bring it up
on the list cause it feels like expected behavior (other git commands
behave correspondingly).

On Fri, Feb 25, 2011 at 2:05 PM, Michael J Gruber <git@drmicha.warpmail.net> wrote:

Indeed it is. Neat command, thanks again!

Michael, my comment was about "reverting the changes from the old commit, but only for specified path/file", sorry about non quoting it.

I think that ''the old commit" is HEAD~1, so reverting it is about checking out HEAD~2, and commiting the results. The same is for a given file.

On Fri, Feb 25, 2011 at 11:38 AM, Thomas Ferris Nicolaisen <tfnico@gmail.com> wrote:

Yeah, and may be your reasoning is better for the principle of least surprise.

Cheers, Dario

Thomas Ferris Nicolaisen <tfnico@gmail.com> writes:

I am afraid that it would lead to encouraging people to record a horribly broken history, unless you think carefully about what the resulting commit log message should describe. It would look _as if_ you negated the effect of the original commit as a whole, but in reality you are only reverting just a part of what you chose to revert with <path>.

We do encourage people to record the _reason_ why the particular commit was removed by not supporting "-m <message>" option to "git revert" command, but the commit template in the editor given to the user should make it absolutely clear that the particular partial revert is reverting only a part of the original commit, and need additional words to strongly encourage to record why only that part and not other parts are reverted.

On Fri, Feb 25, 2011 at 19:53, Junio C Hamano <gitster@pobox.com> wrote:

Agreed, but FWIW where I work I've seen people record "horribly broken history" already because git-revert doesn't support this, and they don't know the trick I described.

I also don't agree that the history would be horribly broken. The message is just an advisory template, it's always the content that changed that we care about, and we can analyze the history and see that this chunk is the reverse of a chunk in a previous commit.

But just like we now have:

    Revert "some commit"

    This partially reverts commit <sha1>.

We could have with <path>:

    Revert "some commit"

    This partially reverts commit <sha1>. Only the path <path> has
    been reverted, which is X out of Y files changed in the original
    commit.

Or something like that.

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

Yes, that is exactly what I was suggesting, no?

On the similar line of thought, it might be a good idea to update the commit template we give slightly perhaps like...

     Revert "some commit"

     This partially reverts commit <sha1>.
    +#
    +# DESCRBE HERE how the change in <sha1>
    +# was a wrong thing to do.

On Fri, Feb 25, 2011 at 20:54, Junio C Hamano <gitster@pobox.com> wrote:

Yes in the second paragraph, I was mainly just going to expand on it and provide a suggestion.

But I mainly wanted to point out that not having this feature means that people do completely manual reverts. So I think we'd have less "broken" history (message), not more as a result of this sort of thing.

Yes this looks very good. Aside from the UI issue of someone expanding on why they did that *inside the comment* because that's what it suggests :)

    This partially reverts commit <sha1>.

    # DESCRIBE ABOVE ...

Would probably be better.

On Fri, Feb 25, 2011 at 2:54 PM, Junio C Hamano <gitster@pobox.com> wrote:

<bikeshed> Maybe:

      Partially revert "some commit"

to make it easier to notice in summaries. </bikeshed>

j.

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

Perhaps you want to do something like:

     git revert <commit> <path1> <path2> ...

In such case the text "Only de path <path>..." makes no sense. I think something like:

     Partial Revert (x/y) "some commit"

     This partially reverts commit <sha1>

...whould be a better choice. Summaries will show that 'x' of the 'y' files committed in <sha1> have been reverted.

Cheers