Edit a specific commit and reapply subsequent commits

Question

I am currently submitting open-source code and the structure of commits are quite strict. I have three commits, let's call them A, B and C. It is important to note that all changes are within the same file.

Furthermore, I have received feedback on code within all three commits. Is it possible to drop into the staged code of, for example, commit B, edit a few lines of code, recommit and then reapply C without much hassle?

The best way I can think of right now is to undo all three commits and then go through the chunk staging again, which will take time to get perfect, since some code are in proximity.

I think you want an interactive rebase. It will give you a list of commits and allow you to edit or just apply each one as desired. — xdhmoore, Apr 29 '21 at 08:08
Similar problem [here](https://stackoverflow.com/questions/32315156/how-to-inject-a-commit-between-some-two-arbitrary-commits-in-the-past) with similar proposed solutions. Might be worth a look. — Romain Valeri, Apr 29 '21 at 08:28

score 2 · Accepted Answer · answered Apr 29 '21 at 08:16

However you achieve the result, when you are done, you will not use the original three commits. If you're allowed to leave A 100% alone, you can keep the original A, but if you must touch B, you won't have the original B any more, and must therefore make a new copy of C as well.

So far, that's just a statement of fact, and not advice on how to achieve what you want. The way to get what you want is—usually—to use git rebase -i.

Let's say you're on branch feature right now:

...--o--o--o--o   <-- main
               \
                A--B--C   <-- feature (HEAD)

You simply run git rebase -i main and Git comes up with an instruction sheet that tells Git to keep the three commits as-as:

# instructions
pick <hash-of-A> <subject-of-A>
pick <hash-of-B> <subject-of-B>
pick <hash-of-C> <subject-of-C>

Change the second pick to edit and write the instruction sheet back and exit your editor.¹ Git will now start by trying to copy commit A directly in place, which will succeed. It will then continue by trying to copy commit B in place, which will also succeed, but now it will stop in the middle of this copying:

...--o--o--o--o   <-- main
               \
                A--B   <-- HEAD
                    \
                     C   <-- feature

You will be in detached HEAD mode, with HEAD selecting commit B.

You can now make changes to the file(s) you would like to change, git add, and run git commit --amend. The --amend will have Git make the new commit—let's call it B'—using commit A as its parent, instead of commit B. The result looks like this:

...--o--o--o--o   <-- main
               \
                A--B'  <-- HEAD
                 \
                  B--C   <-- feature

You can now run git rebase --continue to make Git go on to the pick C command. This will cherry-pick commit C, making a new commit that we'll call C'. Some merge conflicts can occur here, because cherry-pick is actually a merge. If so, you'll need to fix them up and resume again before commit C' can be made. If no conflicts occur, though, we are now in this state:

...--o--o--o--o   <-- main
               \
                A--B'-C'  <-- HEAD
                 \
                  B--C   <-- feature

This completes the set of operations that the interactive rebase is to perform, so it now does the last trick of any rebase, which is to yank the branch name to "here" (wherever HEAD is now) and re-attach your HEAD:

...--o--o--o--o   <-- main
               \
                A--B'-C'  <-- feature (HEAD)
                 \
                  B--C   [abandoned]

Should you want to see the original commits, they still exist: you just have to find the hash ID of original commit C. This is available in:

ORIG_HEAD, for just a brief time (because ORIG_HEAD keeps getting overwritten);
the reflog for HEAD, for at least 30 more days by default; and
the reflog for branch feature, for at least 30 more days by default.

The reflog entries have numeric-suffixed names: feature@{1}. You can also use time-relative names, such as HEAD@{yesterday}. Generally, if some name has had more than one change in any given time period, you'll want to run git reflog, though, instead of trying to guess something like "yesterday.10.am".

¹If you have a long-running editor (some variants of emacs, atom, etc), use whatever method it has to signal back to the waiting Git that this one file is done now and Git should resume.

`git rebase -i` using `edit` is exactly what I was looking for. Thank you for your very explanatory answer. — Hedam, Apr 29 '21 at 12:56

Jevon Kendon · Answer 2 · 2021-04-29T08:27:03.517

2

Maybe.

I'm paranoid with Git, so I always tread slow.

Create a new branch from commit A (the first commit, I assume)
Git amend the last commit, which should be A, and you can update the comments. You get A' - it's like A but a new commit because you mutated it
Git cherry pick commit B into the new branch. Git amend the last commit, which will be B' (it was cherry picked, so a new commit as well)
Git cherry pick commit C into the new branch. You get the idea.

It's a safe approach. Your original commits are still on the original branch. Your new branch has the same logical commits, but with the changes you wanted.

Push the new branch to git hub. Work with that one.

edited Apr 29 '21 at 08:27

answered Apr 29 '21 at 08:19

Jevon Kendon

545
4
13

2

This is the manual method of doing `git rebase` after creating a new branch name that points to the same final commit as the existing branch. Nothing wrong with this method, it's just more work than using `git rebase -i`. – torek Apr 29 '21 at 08:34
You're a brave soul. I'll see if I can get more comfortable with rebase. – Jevon Kendon Apr 29 '21 at 08:52
@JevonKendon I took a backup of the folder before rebasing. Nonetheless, I would only force-push being sure that it is OK, so I could just restore from remote if I screwed up. – Hedam Apr 29 '21 at 12:57

Edit a specific commit and reapply subsequent commits

2 Answers2