How to revert to a specific commit?

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?

On Mon, Dec 2, 2024 at 4:15 AM tao lv <thebookofunknowable@gmail.com> wrote:

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:

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.)

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

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.

On Mon, Dec 2, 2024 at 4:57 PM Junio C Hamano <gitster@pobox.com> wrote:

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

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

On Mon Dec 2, 2024 at 12:40 PM CET, tao lv wrote:

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