How do you remove a specific revision in the git history?

Question

Suppose your git history looks like this:

1 2 3 4 5

1–5 are separate revisions. You need to remove 3 while still keeping 1, 2, 4 and 5. How can this be done?

Is there an efficient method when there are hundreds of revisions after the one to be deleted?

This question is ill-defined. It does not explicitly say that the author wants 1-2-(3+4)-5 or 1-2-4-5 — RandyTek, Jul 20 '16 at 06:15
Well 8 years later, I can't tell you exactly what problem I was trying to solve. But in git there are always a lot of ways to do something, and there are a lot of answers that various people have liked, so I guess the ambiguity isn't causing too many people a lot of difficulty — 1800 INFORMATION, Jul 20 '16 at 20:53
`git rebase --onto 2 3 HEAD` pretty much means rebase onto 2, with commits between 3 and HEAD (HEAD is optional, or 5 in this case) — neaumusic, Dec 05 '17 at 20:50

score 150 · Answer 1 · edited May 23 '17 at 12:10

150

Per this comment (and I checked that this is true), rado's answer is very close but leaves git in a detached head state. Instead, remove HEAD and use this to remove <commit-id> from the branch you're on:

git rebase --onto <commit-id>^ <commit-id>

edited May 23 '17 at 12:10

Community

1
1

answered Nov 15 '12 at 00:50

kareem

1,601
1
10
10

1

If you could tell me how to also remove that commit-id from history based off of just commit-id, you'd be my hero. – kayleeFrye_onDeck Feb 11 '16 at 07:15
3

Can you please include explanation what the magic command does into the answer? I.e. what each parameter denotes? – alexandroid Dec 14 '16 at 18:06
this is awesome but what if i want to remove the very first commit in the history? (which is why i came here :P) – Sterling Camden Jan 19 '17 at 05:15
2

For some reason, nothing happens when I run this. However, changing `^` to `~1` made it work. – Antimony Jun 01 '17 at 22:03
Way late, but I'm going to add that if you run into merge conflicts, abort the rebase and then rerun it with `--strategy-option theirs` on the end. – LastStar007 Feb 26 '19 at 00:39
Also, if you need to remove the commit from a remote repository (e.g. if you've accidentally pushed sensitive info), `git pull --strategy-option ours`, `git push`. – LastStar007 Feb 26 '19 at 00:39
For me, this removed the commit from the history, but the change of the commit to the tracked files was not removed. Was that the intention? – Keith Bennett Apr 08 '22 at 04:36

score 126 · Answer 2 · edited May 02 '11 at 19:41

126

Here is a way to remove non-interactively a specific <commit-id>, knowing only the <commit-id> you would like to remove:

git rebase --onto <commit-id>^ <commit-id> HEAD

edited May 02 '11 at 19:41

mpontillo

13,559
7
62
90

answered Sep 14 '10 at 00:12

rado

4,040
3
32
26

3

Worked for me too. Btw, what does the ^ operator do? Does it mean the next commit after the specified one? – hopia Nov 11 '12 at 20:38
3

@hopia it means the (first) parent of the specified commit. See "git help revisions" – Emil Styrke Mar 28 '13 at 09:09
12

See @kareem's recommendation in his answer to omit `HEAD` so as to avoid a detached head. – mklement0 Sep 03 '13 at 21:31
1

Much easier than having to figure out how many commits back to search. – Dana Woodman Nov 18 '13 at 21:28
1

this is awesome but what if i want to remove the very first commit in the history? (which is why i came here :P) – Sterling Camden Jan 19 '17 at 05:16
Could you explain? – Zeus Jan 25 '19 at 14:20
How to fix the detached HEAD in this case? – inquisitive Apr 04 '23 at 11:25

score 82 · Answer 3 · edited Mar 22 '13 at 14:50

82

As noted before git-rebase(1) is your friend. Assuming the commits are in your master branch, you would do:

git rebase --onto master~3 master~2 master

Before:

1---2---3---4---5  master

After:

1---2---4'---5' master

From git-rebase(1):

A range of commits could also be removed with rebase. If we have the following situation:
E---F---G---H---I---J  topicA
then the command
git rebase --onto topicA~5 topicA~3 topicA
would result in the removal of commits F and G:
E---H'---I'---J'  topicA
This is useful if F and G were flawed in some way, or should not be part of topicA. Note that the argument to --onto and the parameter can be any valid commit-ish.

edited Mar 22 '13 at 14:50

bonh

2,863
2
33
37

answered Nov 05 '10 at 23:34

rvernica

1,208
11
11

3

shouldn't this be `--onto master~3 master~1`? – mxk Mar 30 '11 at 13:56
3

If you simply want to delete the last commit, it's --onto master~1 master – MikeHoss Jul 24 '12 at 15:43
1

I would like to carry this sol. but I get the `MERGE CONFLICT` error. I used scenario mentioned in http://stackoverflow.com/questions/2938301/remove-specific-commit and am unable to remove the 2nd commit in that example. – maan81 Sep 27 '14 at 04:44

score 80 · Accepted Answer · edited Nov 06 '14 at 02:19

To combine revision 3 and 4 into a single revision, you can use git rebase. If you want to remove the changes in revision 3, you need to use the edit command in the interactive rebase mode. If you want to combine the changes into a single revision, use squash.

I have successfully used this squash technique, but have never needed to remove a revision before. The git-rebase documentation under "Splitting commits" should hopefully give you enough of an idea to figure it out. (Or someone else might know).

From the git documentation:

Start it with the oldest commit you want to retain as-is:

git rebase -i <after-this-commit>

An editor will be fired up with all the commits in your current branch (ignoring merge commits), which come after the given commit. You can reorder the commits in this list to your heart's content, and you can remove them. The list looks more or less like this:
pick deadbee The oneline of this commit
pick fa1afe1 The oneline of the next commit
...
The oneline descriptions are purely for your pleasure; git-rebase will not look at them but at the commit names ("deadbee" and "fa1afe1" in this example), so do not delete or edit the names.

By replacing the command "pick" with the command "edit", you can tell git-rebase to stop after applying that commit, so that you can edit the files and/or the commit message, amend the commit, and continue rebasing.

If you want to fold two or more commits into one, replace the command "pick" with "squash" for the second and subsequent commit. If the commits had different authors, it will attribute the squashed commit to the author of the first commit.

-1 The question well defined but this answer is not so clear. The author does not say what the exact solution is. — Aleksandr Levchuk, Apr 03 '11 at 07:26
This is a wrong lead. The SPLITTING COMMITS section is not the correct one. You want to read much higher in the manual - see @Rares Vernica's answer. — Aleksandr Levchuk, Apr 03 '11 at 08:22
@AleksandrLevchuk The question is not well-defined: it is unclear from the way the question is stated whether the changeset in 3 is to be kept or discarded. I will agree that if the changes are to be discarded, the other answers offer an easier approach. If the changes are to be kept, however, this would be a purely cosmetic operation. Both approaches rewrite history in ways that are dangerous if others may have based work on top of the flawed history; if that is the case, the cosmetic cleanup should not be done, and the change deletion would be better done via git revert. — Theodore Murdock, Aug 13 '14 at 17:19

score 23 · Answer 5 · answered Sep 05 '08 at 16:16

If all you want to do is remove the changes made in revision 3, you might want to use git revert.

Git revert simply creates a new revision with changes that undo all of the changes in the revision you are reverting.

What this means, is that you retain information about both the unwanted commit, and the commit that removes those changes.

This is probably a lot more friendly if it's at all possible the someone has pulled from your repository in the mean time, since the revert is basically just a standard commit.

Unfortunately not a good solution for me because someone accidentally committed 100MB of crap to the repo, blowing up the size and making the web interface sluggish. — Stephen Smith, Jan 18 '14 at 15:25

jdsumsion · Answer 6 · 2012-09-25T04:56:31.090

All the answers so far don't address the trailing concern:

Is there an efficient method when there are hundreds of revisions after the one to be deleted?

The steps follow, but for reference, let's assume the following history:

[master] -> [hundreds-of-commits-including-merges] -> [C] -> [R] -> [B]

C: commit just following the commit to be removed (clean)

R: The commit to be removed

B: commit just preceding the commit to be removed (base)

Because of the "hundreds of revisions" constraint, I'm assuming the following pre-conditions:

there is some embarrassing commit that you wish never existed
there are ZERO subsequent commits that actually depend on that embarassing commit (zero conflicts on revert)
you don't care that you will be listed as the 'Committer' of the hundreds of intervening commits ('Author' will be preserved)
you have never shared the repository
- or you actually have enough influence over all the people who have ever cloned history with that commit in it to convince them to use your new history
- and you don't care about rewriting history

This is a pretty restrictive set of constraints, but there is an interesting answer that actually works in this corner case.

Here are the steps:

git branch base B
git branch remove-me R
git branch save
git rebase --preserve-merges --onto base remove-me

If there are truly no conflicts, then this should proceed with no further interruptions. If there are conflicts, you can resolve them and rebase --continue or decide to just live with the embarrassment and rebase --abort.

Now you should be on master that no longer has commit R in it. The save branch points to where you were before, in case you want to reconcile.

How you want to arrange everyone else's transfer over to your new history is up to you. You will need to be acquainted with stash, reset --hard, and cherry-pick. And you can delete the base, remove-me, and save branches

Worked for me to remove 3 commits in sequence from the middle of the history of a branch where someone committed a bunch of 150mb files. — Marcos, Sep 02 '19 at 16:12

score 3 · Answer 7 · answered Sep 06 '16 at 22:54

3

I also landed in a similar situation. Use interactive rebase using the command below and while selecting, drop 3rd commit.

git rebase -i remote/branch

answered Sep 06 '16 at 22:54

Sankalp

1,182
2
17
22

score 2 · Answer 8 · answered Nov 05 '14 at 09:09

So here is the scenario that I faced, and how I solved it.

[branch-a]

[Hundreds of commits] -> [R] -> [I]

here R is the commit that I needed to be removed, and I is a single commit that comes after R

I made a revert commit and squashed them together

git revert [commit id of R]
git rebase -i HEAD~3

During the interactive rebase squash the last 2 commits.

score 0 · Answer 9 · answered Sep 14 '17 at 07:51

Answers of rado and kareem do nothing for me (only message "Current branch is up to date." appears). Possibly this happens because '^' symbol doesn't work in Windows console. However, according to this comment, replacing '^' by '~1' solves the problem.

git rebase --onto <commit-id>^ <commit-id>

How do you remove a specific revision in the git history?

9 Answers9

Linked

Related