While a rebase sequence is in progress, the status buffer features a section that lists the commits that have already been applied as well as the commits that still have to be applied.
The commits are split in two halves. When rebase stops at a commit,
either because the user has to deal with a conflict or because s/he
explicitly requested that rebase stops at that commit, then point is
placed on the commit that separates the two groups, i.e. on
commits above it have not been applied yet, while the
HEAD and the
commits below it have already been applied. In between these two
groups of applied and yet-to-be applied commits, there sometimes is a
commit which has been dropped.
Each commit is prefixed with a word and these words are additionally shown in different colors to indicate the status of the commits.
The following colors are used:
HEAD(e.g. because you haven’t done anything yet after rebase stopped at the commit, then this commit is shown in blue, not green). There can only be a green and a blue commit at the same time, if you create one or more new commits after rebase stops at a commit.
Of course these colors are subject to the color-theme in use.
The following words are used:
fixuphave not been applied yet. These words have the same meaning here as they do in the buffer used to edit the rebase sequence. See Editing Rebase Sequences. When the
--rebase-mergesoption was specified,
mergelines may also be present.
ontohave already been applied. It is possible for such a commit to be the
HEAD, in which case it is blue. Otherwise it is grey.
ontois the commit on top of which all the other commits are being re-applied. This commit itself did not have to be re-applied, it is the commit rebase did rewind to before starting to re-apply other commits.
donehave already been re-applied. This includes commits that have been re-applied but also new commits that you have created during the rebase.
To determine whether a commit is related to the stopped-at commit their hashes, trees and patch-ids 1 are being compared. The commit message is not used for this purpose.
Generally speaking commits that are related to the stopped-at commit can have any of the used colors, though not all color/word combinations are possible.
Words used for stopped-at commits are:
void, then that indicates that Magit knows for sure that all the changes in that commit have been applied using several new commits. This commit is no longer reachable from
HEAD, and it also isn’t one of the commits that will be applied when resuming the session.
join, then that indicates that the rebase sequence stopped at that commit due to a conflict - you now have to join (merge) the changes with what has already been applied. In a sense this is the commit rebase stopped at, but while its effect is already in the index and in the worktree (with conflict markers), the commit itself has not actually been applied yet (it isn’t the
HEAD). So it is shown in yellow, like the other commits that still have to be applied.
stopor a blue or green
same, then that indicates that rebase stopped at this commit, that it is still applied or has been applied again, and that at least its patch-id is unchanged.
stop, then that indicates that rebase stopped at that commit because you requested that earlier, and its patch-id is unchanged. It might even still be the exact same commit.
same, then that indicates that while its tree or hash changed, its patch-id did not. If it is blue, then it is the
HEADcommit (as always for blue). When it is green, then it no longer is
HEADbecause other commit have been created since (but before continuing the rebase).
goal, a yellow
work, then that indicates that rebase applied that commit but that you then reset
HEADto an earlier commit (likely to split it up into multiple commits), and that there are some uncommitted changes remaining which likely (but not necessarily) originate from that commit.
goal, then that indicates that it is still possible to create a new commit with the exact same tree (the "goal") without manually editing any files, by committing the index, or by staging all changes and then committing that. This is the case when the original tree still exists in the index or worktree in untainted form.
same, then that indicates that it is no longer possible to create a commit with the exact same tree, but that it is still possible to create a commit with the same patch-id. This would be the case if you created a new commit with other changes, but the changes from the original commit still exist in the index or working tree in untainted form.
work, then that indicates that you reset
HEADto an earlier commit, and that there are some staged and/or unstaged changes (likely, but not necessarily) originating from that commit. However it is no longer possible to create a new commit with the same tree or at least the same patch-id because you have already made other changes.
gone, then that indicates that rebase applied that commit but that you then reset
HEADto an earlier commit (likely to split it up into multiple commits), and that there are no uncommitted changes.
poof, then that indicates that it is no longer reachable from
HEAD, but that it has been replaced with one or more commits, which together have the exact same effect.
gone, then that indicates that it is no longer reachable from
HEADand that we also cannot determine whether its changes are still in effect in one or more new commits. They might be, but if so, then there must also be other changes which makes it impossible to know for sure.
Do not worry if you do not fully understand the above. That’s okay, you will acquire a good enough understanding through practice.
For other sequence operations such as cherry-picking, a similar section is displayed, but they lack some of the features described above, due to limitations in the git commands used to implement them. Most importantly these sequences only support "picking" a commit but not other actions such as "rewording", and they do not keep track of the commits which have already been applied.
The patch-id is a hash of the changes introduced by a commit. It differs from the hash of the commit itself, which is a hash of the result of applying that change (i.e. the resulting trees and blobs) as well as author and committer information, the commit message, and the hashes of the parents of the commit. The patch-id hash on the other hand is created only from the added and removed lines, even line numbers and whitespace changes are ignored when calculating this hash. The patch-ids of two commits can be used to answer the question "Do these commits make the same change?".