How to revert to a specific commit?

How to revert to a specific commit?

[tao lv]

I want to revert the code to a specific commit. This commit is not a
direct part of the branch history; there are merge operations, branch
forks, and other changes in between. Therefore, directly using `revert
HEAD...commit` fails due to merge need -m.

I don't want to revert each individual commit; I just want to restore
the code to this specific commit while retaining all the current
history commits.

How can I achieve this? Is there a better way than using the revert function?

Re: How to revert to a specific commit?

[Chris Torek]

On Mon, Dec 2, 2024 at 4:15 AM tao lv <thebookofunknowable@gmail.com> wrote:
> I want to revert the code to a specific commit. ...

OK, first some background:

 * A commit _is_ a full snapshot of every file, as of the state
   it had at the time you (or whoever) made that particular
   commit. Hence, if you want the particular files from a
   particular commit, you simply check out that (historical)
   commit.

Now:

> I don't want to revert each individual commit; I just want to restore
> the code to this specific commit while retaining all the current
> history commits.
>
> How can I achieve this? Is there a better way than using the revert function?

Yes.

The mechanics of:

    git checkout <hash-ID-or-other-commit-specifier>

are twofold, and mean the same thing as:

    git switch --detach <same-hash-ID-etc>

That is, you are asking Git to:

 1) switch to the saved snapshot, and
 2) "detach HEAD".

Step 2 is your problem here because the jargon phrase
"detach HEAD" means "stop being on any branch at all,
just go to some historical commit". But you seem to want
to subsequently make a *new* commit that contains the
*old snapshot*, as if you had removed all the work you
(or anyone else) had done since that point in time and put
all the files back the way they were in the historical commit,
*while remaining on your branch*, so that you are now
ready to commit all the old versions of the files.

Note that this new commit, if and when you make it,
simply sits atop the history (and / but, since every commit
is a full snapshot of all files, it undoes all the *work* done
since the restored commit -- though, since all commits
are also *permanent*, that undone work can be redone
trivially as well).

So, at this point, you have several options for
achieving this goal, provided I have recapitulated
your goal correctly.  The most obvious, I think, is:

    git checkout [--detach] <hash>   # or git switch --detach <hash>
    git reset --soft <branch-name>

The checkout-or-switch does what it does, including
detaching HEAD, and then the `git reset --soft` tells Git
that it should re-attach `HEAD` to the given branch name,
but not alter *either* the index / staging-area, *or* the
working tree, leaving the historical versions of all files
as "ready to commit".

=====

A different, and more direct, option is to use:

    git restore --no-overlay -S -W <hash>

The `git checkout` command can be used in place
of this `git restore`, because `git checkout` itself is (in
my opinion) overly complicated and stuffed full of modes,
so that it has a mode in which it *doesn't* affect `HEAD`.
Understanding this requires keeping in mind the way
I described `git checkout` has having a step-1-then-step-2,
even though the two-step `git checkout` actually very
carefully *combines* the two steps (to avoid making any
changes should the second step be about to fail for some
reason). I find that describing checkout as two separate
steps, and literally using an additional `git reset --soft`
step, more explainable (Git is complicated! Nobody learns
all of it, it is always changing over time! Those new to it
find it very mysterious, and this is part of why).

Chris

(PS: the fact that you need `--no-overlay` with the
single-step methods is another one of those picky
little details that make Git tricky.)

Re: How to revert to a specific commit?

[Junio C Hamano]

Chris Torek <chris.torek@gmail.com> writes:

> On Mon, Dec 2, 2024 at 4:15 AM tao lv <thebookofunknowable@gmail.com> wrote:
>> I want to revert the code to a specific commit. ...
>
> OK, first some background:
>
>  * A commit _is_ a full snapshot of every file, as of the state
>    it had at the time you (or whoever) made that particular
>    commit. Hence, if you want the particular files from a
>    particular commit, you simply check out that (historical)
>    commit.
>
> Now:
>
>> I don't want to revert each individual commit; I just want to restore
>> the code to this specific commit while retaining all the current
>> history commits.
>>
>> How can I achieve this? Is there a better way than using the revert function?
>
>     git checkout [--detach] <hash>   # or git switch --detach <hash>
>     git reset --soft <branch-name>
>
>     git restore --no-overlay -S -W <hash>

While that would _work_ in the sense that you can revert the effect
of what the discarded commits did, I would not recommend any of the
above since it does not leave any record of what you discarded.

Imagine that I regret doing everything since we tagged, say, v2.47.0
release and want to discard everythig on 'master' newer than that
commit.  If I want to "keep" the history of failed commits that I
regret having made since v2.47.0, here is a way to do it:

 $ git checkout master
 $ git reset --hard v2.47.0
 $ git merge -s ours --no-ff -m 'Discard everything since v2.47.0' master@{1}

The first two steps just discard the unwanted commits.  The third
step is a trick to

 - Keep the tree contents of the current commit (i.e. -s ours) as
   the result,

 - Make sure the result is recorded as a merge commit (i.e.
   --no-ff), not "fast-forward" to the tip of the history I am
   discarding, and

 - Record the discarded history (i.e. master@{1}) as the side branch
   of the resulting history.

The last part would help if I later need to merge changes that were
based on 'master' I am discarding.  The presense of the side branch
makes sure that only the effects from the new work done on the
discarded history, and not from the commits such a new work was
based on (which are the commits I regret having made and I am
discarding), are taken into account when computing further merges.

Re: How to revert to a specific commit?

[Chris Torek]

On Mon, Dec 2, 2024 at 4:57 PM Junio C Hamano <gitster@pobox.com> wrote:
> While [Torek's sequence of commands] would _work_ in the  sense
> that you can revert the effect of what the discarded commits
> did, I would not recommend any of the above since it does not
> leave any record of what you discarded.

[alternate method with `git merge -s ours --no-ff` snipped, but note
that it will do this:]

>  - Record the discarded history (i.e. master@{1}) as the side branch
>    of the resulting history.

This is a good point and illustrates the key issue I left out.. I was
describing (and kind of deliberately hammering on, for teaching
purposes) the fact that every commit node in the commit graph
records the _full state of all files_ as of that particular commit.
Hence if the only thing you care about is "state of files", that's
also the only part of a commit that matters.

But commits do one other thing, in addition to the usual housekeeping
work of remembering who made them and when and a log message.
That specific other thing is: each commit remembers a list[1] of
_previous commits_, and stringing this commit up after its
predecessor(s) is what produces "history".

That is, Git does not _store_ history (specifically, history of files).
Instead, it stores the _information needed to discover history
any time you wish to discover it_. The list-of-previous commits
is how this works. Using a merge allows you to store a list of
_two or more_ previous commits. The _first_ entry in this list,
which is often the only entry, is what we think of as "the immediate
previous commit", and following this list-of-first-entries gives you
the history of what happened to each file.

Second (and additional) list entries, if present, help you figure
out _how_ you got this particular version of every file in this
particular commit, in the usual merge cases. In unusual cases
(such as Junio's method here) it can help you figure out what
you deliberately left behind, and the fact that the new commit is
a merge commit -- a commit with two or more parents, instead
of just one -- is a clue that something out of the ordinary
occurred.

[1] I say "list" instead of "set" here because order matters:
the first entry is special. "Set" would also imply de-duplication.
While the list entries don't normally contain any duplicates,
there's nothing in the machinery to prevent them. What (if
anything) such duplicates might mean -- well, that's up to you.

Chris

Re: How to revert to a specific commit?

[Matěj Cepl]

[-- Attachment #1.1.1: Type: text/plain, Size: 771 bytes --]

On Mon Dec 2, 2024 at 12:40 PM CET, tao lv wrote:
> I don't want to revert each individual commit; I just want to restore
> the code to this specific commit while retaining all the current
> history commits.

Either git checkout <commit-id> for an inspection or git reset
--hard <commit-id> for change of the current branch to that
commit.

Matěj

-- 
http://matej.ceplovi.cz/blog/, @mcepl@floss.social
GPG Finger: 3C76 A027 CA45 AD70 98B5  BC1D 7920 5802 880B C9D8
 
Books aren’t written - they’re rewritten. Including your own. It
is one of the hardest things to accept, especially after the
seventh rewrite hasn’t quite done it.
  -- Michael Crichton, alluding to Steele MacKaye (1889) article
     where he said this about theater plays.


[-- Attachment #1.2: E09FEF25D96484AC.asc --]
[-- Type: application/pgp-keys, Size: 3102 bytes --]

-----BEGIN PGP PUBLIC KEY BLOCK-----

mQGiBD2g5T0RBACZdnG/9T4JS2mlxsHeFbex1KWweKPuYTpnbu8Fe7rNYMWZ/AKc
9Vm+RuoVErm4HGsb0pL5ZPnncA+m80W8EzQm2rs8PD2mHNsUhDOGnk+0fm+25WSU
6YLzd8lttxPia75A5OqBEAmJlyJUSmoWKjAK/q1Tj5HW3+/7XqWYYCJzAwCgjR2D
irw8QP8GCoUUXxeNpIOTqzMD/j66VTln+rxYT12U4jxLlsOs5Y0LVQfUbpDFEYy9
mkWX8iNTUZsx+m6uhylamm3EkN/dW0b2sQ4D3ocZekriLPDR/X0P1XPUdcy28a6o
WZoVAKN26X+PwxSq3JCiQEJgPJeKxiLiExh3lDitNyAS0WUD/xQOqryEFb9ksGxL
R9UCA/9WUQMwgQvEUhuVB7qSnREo3+ks34Kltp71uUjuMjLk3ykSptyn8oV+XZgx
rxPAD+WOJn51yFxbo+OPNdH6wG2ZaXFj47rX6GQ9W6wI7K0QhdyQTps8KNlsJuDQ
pz7XME98ob8SszsvkPPm/gX0oWdOIqHipHnMlL684jRHCWHVjrQdTWF0ZWogQ2Vw
bCA8bWF0ZWpAY2VwbG92aS5jej6IYAQTEQIAIAIeAQIXgAIZAQUCRSoWAgYLCQgH
AwIEFQIIAwQWAgMBAAoJEOCf7yXZZISsr5sAoIAqsNcs1Sl9jrmqv7vJzL4QG68V
AJ9+30NmBClQwpmqnA26nCa4+WS5abQbTWF0ZWogQ2VwbCA8Y2VwbC5tQG5ldS5l
ZHU+iGAEExECACACGwMCHgECF4AFAkUqFgkGCwkIBwMCBBUCCAMEFgIDAQAKCRDg
n+8l2WSErAULAJoC8yrptOgooJOzLzmLxDc1mzeGDACdFBwZlvFcj1T2dmCRNdn5
cErRyBe0G01hdMSbaiBDZXBsIDxtY2VwbEBjZXBsLmV1PohiBBMRAgAiBQJQixpw
AhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRDgn+8l2WSErBMYAJ9eQEpi
bL6Vm7sUOhupxD/UsHiWlQCdHYi+UNpzC1mKYtDSWa1ocfO1Q760HE1hdGVqIENl
cGwgPGNlcGxtQHNlem5hbS5jej6IYAQTEQIAIAIbAwIeAQIXgAUCRSoWCQYLCQgH
AwIEFQIIAwQWAgMBAAoJEOCf7yXZZISsP14Ani6U87hSUXDU+3ZTaDRXIwasTttl
AJ0QWhjSmaJTdkkpfqmRB9bRi9pAQbQfTWF0xJtqIENlcGwgPGNlcGxAc3VyZmJl
c3QubmV0PohgBBMRAgAgAhsDAh4BAheABQJFKhYJBgsJCAcDAgQVAggDBBYCAwEA
CgkQ4J/vJdlkhKwBBwCbBOoTY52hYeKnKuU/uRjOTsUMg3IAnjTTrXYHD49xyLs8
T/Vpsuk6ZP/htCFNYXRlaiBDZXBsIDxtYXRlai5jZXBsQGdtYWlsLmNvbT6IYAQT
EQIAIAIbAwIeAQIXgAUCRSoWCQYLCQgHAwIEFQIIAwQWAgMBAAoJEOCf7yXZZISs
ki0An0Gw1MjZJATtVq11Su0mjd3rDQChAJ0eePE0amSwYVGSpSNb264+XjUotrQs
TWF0ZWogQ2VwbCAoUmVkSGF0IEN6ZWNoKSA8bWNlcGxAcmVkaGF0LmNvbT6IYAQT
EQIAIAUCRSyciwIbAwYLCQgHAwIEFQIIAwQWAgMBAh4BAheAAAoJEOCf7yXZZISs
byQAniqw1PX24BlbBD22zNqYwzfIPDhwAJ4m/3ytuJzsfxrEac1tSoEb2+H9vrQ5
TWF0ZWogQ2VwbCA8Y2VwbC1aTzRGMEtubUNESGsxdU1KU0JrUW1RQHB1YmxpYy5n
bWFuZS5vcmc+iGAEExECACACGwMCHgECF4AFAkUqFgkGCwkIBwMCBBUCCAMEFgID
AQAKCRDgn+8l2WSErAn9AJ9bO0NUqLnMDTCcchtVzK6yEOLkCgCfXwkty1uEAzQI
5kt9Gec8yQpxDli0Gk1hdGVqIENlcGwgPG1jZXBsQHN1c2UuZGU+iGMEExECACMF
Alr65CsCGwMHCwkIBwMCAQYVCAIJCgsEFgIDAQIeAQIXgAAKCRDgn+8l2WSErHjO
AJ47yF9STX/Es4qsJPjW961He9H3bgCdEsjOgt7czE87Gy0D1KXWWNTdTtW0G01h
dGVqIENlcGwgPG1jZXBsQHN1c2UuY29tPohjBBMRAgAjBQJa+uQ/AhsDBwsJCAcD
AgEGFQgCCQoLBBYCAwECHgECF4AACgkQ4J/vJdlkhKwsQQCdGmGXW73O6Q3TB0V0
xP9yLwMjDtEAnjKWDW8PKO90nx8IkPodxr1nCvJbtBpNYXRlaiBDZXBsIDxtY2Vw
bEBzdXNlLmN6PohjBBMRAgAjBQJa+uRPAhsDBwsJCAcDAgEGFQgCCQoLBBYCAwEC
HgECF4AACgkQ4J/vJdlkhKyKtQCdHDpolHg/1qDaw/4CQyUzAfNvHk0AniEYL6BF
rdyonhgQf/ZXzXjnKzSeuQENBD2g5UEQBACfxoz2nmzGJz6ueKHkTeXcQZvK4WzK
TN/uJJhEmSuQmOKymbIkGL6vBQb+W4KxvLl2lAbNlfIgLGDLCs1YAwfSpJ4vS4mt
liPgA2OtZ5j1WSOqpxedQPGVba5gVo7HNSOMUtZKTz7VsCvR94v05comhO1Gok75
ZxHtYyVHuk5V8wADBQP/ft+W4F0tccwslzz8O/c9/Mj8KZDYmfMyNb7ielT2WeQ3
iFF9AxMT6OvOxAQbDJvurfKeYlydcXLs6cy4lKce1hFaJ4i+MOFLVV1ZnZDDChRP
pQ6KrRCHLb+mLY+SYD37O7p0spQA+9gsEE/tmn+5sW7LE8hqSOoPVdf7Y5yUDj6I
RgQYEQIABgUCPaDlQQAKCRDgn+8l2WSErEUSAJ42T1l/2TFykbULBqqAtnbC6kR0
wwCdEnRlCGlvnO78R0FgKXlt3RyzGuE=
=sxoW
-----END PGP PUBLIC KEY BLOCK-----

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 216 bytes --]