CODEWITHSUNDEEP
git
scanny
scanny

Reputation: 28863

Viewing the current commit's message during git rebase

During a rebase, I often want to see the message of the commit that's currently being applied, to help make sense of a merge conflict.

I used to run:

$ cat .git/rebase-apply/message

Which would give that to me nicely. However, on my new machine running git v2.20.1, that file no longer exists during a rebase.

Where can I get the message of the commit currently being applied (when the rebase pauses for a merge-conflict)?

Upvotes: 6

Views: 1003

Answers (2)

Wallace
Wallace

Reputation: 17369

In version 2.23, I see the following command:

git am --show-current-patch

It displays the commit message and a lot more.

Upvotes: 1

torek
torek

Reputation: 487755

TL;DR: check for git rev-parse --git-path rebase-merge/message and git rev-parse --git-path rebase-apply/msg in case you are in an added worktree.

Unfortunately, the interface to obtain this information is not stable. However, the file you are seeking does still exist in modern Git.

With the advent of git worktree, most state information has (at least potentially) moved. The same kinds of files now exist, but are in variable locations. To find the location of a file whose git-relative path name is P, use git rev-parse --git-path P:

$ git rev-parse --git-path HEAD
.git/HEAD
$ git worktree add ../git2 --detach
Preparing worktree (detached HEAD 5d826e9729)
HEAD is now at 5d826e9729 Git 2.20
$ (cd ../git2; git rev-parse --git-path HEAD)
[redacted]/git/.git/worktrees/git2/HEAD

As of Git 2.13, the two directories in which rebase information may be found are:

rebase-apply
rebase-merge

(as always, use the git-path trick to locate the actual directories or individual files in them). The files therein are initially symmetric, as the code just sets up a state directory and then drops files into it as needed. The set of files may change in any future Git release; however, there's at least some hope of consistency due to contrib/completion/git-prompt.sh. This looks inside rebase-merge first, if it exists, for:

head-name    the branch you were on when you started the rebase
msgnum       how many commits are already done (how far along are you)
end          the total number of commits to do
interactive  if exists, means this is git rebase -i (vs git rebase -m)

If rebase-merge does not exist, it looks inside rebase-apply (if that exists) for:

next         how many commits are already done (how far along are you)
last         the total number of commits to do
rebasing     if exists, means this is an ordinary git rebase, in which case:
  head-name    the branch you were on when you started rebasing
applying     if exists, means this is a git am without rebase

If neither rebasing nor applying files exist, the prompt code assumes "either git-am or git-rebase" without attempting to guess anything further.

If neither directory exists, the prompt-setting code goes on to check for:

MERGE_HEAD        a merge is in progress
CHERRY_PICK_HEAD  a cherry-pick is in progress
REVERT_HEAD       a revert is in progress
BISECT_LOG        a bisect is in progress

Rather less stable than any of these, the sequencer code (now used for all but legacy rebase, although I'm not sure offhand how much it was used in 2.13) has many more—see all the GIT_PATH_FUNC lines in the source code. One of them is your rebase-merge/message file. Whether you're doing an interactive rebase, a git rebase -m, or git rebase -s strategy, this file should exist, in the appropriate work-tree-dependent path. For a non-interactive git rebase the file should, I think, be in rebase-apply/msg instead.

Upvotes: 4

Related Questions