Git error could not apply

Changing the Last Commit

Fixing a Commit Message

If you use git commit --amend without making any changes to the index, Git still allows you to edit the commit message if you like, or you can give the new message with the -m option. This still requires replacing the last commit, since the message text is part of the commit; the new commit will just have the same content (point to the same tree) as the previous one.

Suppose you’re having an off day and, having committed and then amended that commit, you suddenly realize that you just lost some information from the first commit that you didn’t mean to. You would appear to be out of luck: that commit has been discarded, and unless you happen to have its object ID, you have no way to refer to it, even though it’s still in the object database. Git has a feature to save you, though, called the reflog:

$ git log -g

The git log command, which we will discuss in Chapter 9, normally shows the history of your project via portions of the commit graph. The -g option shows something entirely different, however. For each branch, Git maintains a log of operations performed while on that branch, called its “reflog.” Recall that a branch is just a ref pointing to the tip commit of the branch; each ref can have a log recording its referents over time. git log -g displays a composite reflog, starting with the current branch and chaining back through commands that switch branches, such as git checkout. For example:

$ git log -g
e674ab77 HEAD@{0}: commit (amend): Digital Restrictio…
965dfda4 HEAD@{1}: commit: Digital Rights Management
dd31deb3 HEAD@{2}: commit: Mozart
3307465c HEAD@{3}: commit: Beethoven
6273a3b0 HEAD@{4}: merge topic: Fast-forward
d77b78fa HEAD@{5}: checkout: moving from sol to master
6273a3b0 HEAD@{6}: commit: amalthea
2ee20b94 HEAD@{7}: pull: Merge made by the 'recursive…
d77b78fa HEAD@{8}: checkout: moving from master to sol
1ad385f2 HEAD@{9}: commit (initial): Anfang

The reflog shows the sequence of operations performed: commit, pull, checkout, merge, etc. The notation branch@{n} refers to a numbered entry in the reflog for branch; in this case HEAD, the current branch. The crucial thing for us, though, is the first column of object IDs: each one names the commit that was the branch tip after the operation on that line was completed. Thus, when I made the commit for entry #1 in this reflog, with the comment “Digital Rights Management,” the branch moved to commit 965dfda4, which means this is the ID for that commit. After I used git commit --amend to fix the commit message, the branch looked like this:

$ git log
e674ab77 Digital Restrictions Management
dd31deb3 Mozart
3307465c Beethoven
...

Commit 965dfda4 is absent, removed from the history, but the reflog retains a record of it. You can use git show 965dfda4 to view the diff for that commit and recover the missing information, or git checkout 965dfda4 to move your working tree to that state, if that’s more convenient.

See Names Relative to the Reflog for more about the reflog.

Discarding the Last Commit

In the foregoing description, the only thing limiting the action to “the last commit” is the expression HEAD~; it works just as well to discard any number of consecutive commits at the end of a branch. This action is sometimes called “rewinding the branch.” For example, to discard three commits resetting the branch tip to the fourth commit back, do:

$ git reset HEAD~3

HEAD~3 refers to the fourth commit back, because this numbering syntax starts at zero; HEAD and HEAD~0 are equivalent.

When discarding more than one commit, some further options to git reset become useful:

Undoing a Commit

If you only want to undo some of the changes from an earlier commit, you can use a combination of commands we’ve seen before:

$ git revert -n commit
$ git reset
$ git add -p
$ git commit
$ git checkout .

The -n option to git revert tells Git to apply and stage the reverted changes, but stop short of making a commit. You then unstage all the changes with git reset, and restage only those you want using the interactive git add -p. Finally, after committing the subset of changes you want, you discard the rest by checking out the contents of the index, overwriting the remaining applied changes from git revert.

Plain git revert will complain if you have staged changes in the index (that is, the index does not match the HEAD commit), since its purpose is to make a new commit based on the one to be reverted, and it would lose your changes if it reset the index in order to do that. git revert -n, though, will not complain about that, since it is not making a commit.

Note that if the commit you’re reverting deleted a file, then this will add it back. After git reset though, the recovered file will appear as “untracked” to Git, and git add -p will not see it; you’ll have to add it again separately, if it’s one of the changes you want to make (git add --interactive (-i) can help with that; it’s more general, and git add -p is actually a commonly used subcommand of it). Similarly, the final checkout will not remove a restored file that you chose not to add; you’ll have to remove it yourself. You can use git reset --hard or git clean, but be careful not to accidentally remove other untracked files or revert other working tree changes you may have.

Editing a Series of Commits

pick

Use the commit as-is. Git will not stop for this commit unless there is a conflict.

reword

Change just the commit message. Git allows you to edit the message before reapplying this commit.

edit

Change the commit contents (and message, if you want). Here, Git stops after remaking this commit and allows you to do whatever you want. The usual thing is to use git commit --amend to replace the commit, then git rebase --continue to let Git continue with the rebase operation. However, you could also insert further commits, perhaps splitting the original changes up into several smaller commits. Git simply picks up from where you leave off, with the next change you asked it to make.

squash

Make this commit’s changes part of the preceding one. To meld several consecutive commits into one, leave the first one marked pick and mark the remaining ones with squash. Git concatenates all the commit messages for you to edit.

fixup

Like squash, but discard the message of this commit when composing the composite message.

It’s possible to ask for changes that invalidate the existing commits. For example: if one commit adds a file and a later commit changes that file, and you reverse the order of these commits, then Git cannot apply the new first patch, since it says to alter a file that doesn’t yet exist. Also, patches to existing files rely on context, which may change if you edit the contents of earlier commits. In this case, Git will stop, indicate the problem, and ask you to resolve the conflict before proceeding. For example:

error: could not apply fcff9f72... (commit message)

When you have resolved this problem, run "git rebase
--continue".  If you prefer to skip this patch, run
"git rebase --skip" instead.  To check out the
original branch and stop rebasing, run "git rebase
--abort".

Could not apply fcff9f7... (commit message)

Here, Git uses the same mechanism for indicating conflicts as when performing a merge; see Merge Conflicts for details on how to examine and resolve them. When you’re done, as indicated above, just run git rebase --continue to make the now-repaired commit, and move on to the next edit.

There is actually another action, exec, but you would not edit an existing line in the rebase instructions to use it as with the other actions, since it does not say to do anything with a commit; rather, the rest of the line is a just shell command for Git to run. A typical use for this is to test the preceding commit in some way, to make sure you haven’t accidentally broken the content; you might add exec make test, for example, to run an automated software test. Git will stop if an exec command exits with a nonzero status. You can also give a single command with the git rebase --exec option, which will be run after every commit; this is a shortcut for inserting that same exec line after every commit in the sequencer directions.