1

All the time until today I git was adding me the commit message Merge branch 'name_of_branch' into 'name_of_branch'. It was also adding a list of conflicts which was super cool. But now when I merged a branch with conflicts the message is not there anymore.

How to re-enable it?

I want to do more-less opposite to what is asked here How to avoid "Merge branch 'name_of_branch' in commit messages?.

Community
  • 1
  • 1
Marian Paździoch
  • 8,813
  • 10
  • 58
  • 103
  • Just to be clear, if you do a merge that doesn't have conflicts and thus git automatically commits with that commit message, but if you do a merge with conflicts and do a `git commit`, up pops your editor with the template message that only contains comments, and you want it to suggest the same template for you automatically? Did I get that right? – Lasse V. Karlsen Mar 21 '17 at 12:33
  • Since you specifically mention the list of conflicts, I would point this out: The conflict list is commented out in the commit message editor, so by default *is not* included in the actual commit message. So if you're wondering why the conflicts aren't making it into the log... the only way they ever would is if you uncommented them during the commit – Mark Adelsberger Mar 21 '17 at 13:09

2 Answers2

0

Any git merge sets up a default log message for the ultimate commit. The "default default", i.e., what you get if you don't override the built-in default with your own default or with something explicit, includes both1 the branch names, except when merging into master when it includes only the one non-master branch name.

The actual message itself, however, depends on several items (one of which I already mentioned):

  • Did you run git merge yourself, or let git pull run it for you?
  • Did you use the --squash option?
  • Are you merging using a remote-tracking branch name?
  • Is the current branch named master?
  • Did you use the --log option, or configure merge.log to an integer value or to true?
  • Did you set merge.branchdesc in your configuration?

See also the git fmt-merge-msg documentation as well as the git merge documentation.

If you interactively edit the merge message—this is the default—you have a chance to modify it to your taste. Your prepare-commit-msg and commit-msg hooks also have a chance to modify the message; see the githooks documentation. The git interpret-trailers command may also be useful in a commit message hook (see the example in the documentation).

1"All", for an octopus merge; but most merges just have two branch names involved. And of course, when using raw commit hashes, there are no branch names available.

torek
  • 448,244
  • 59
  • 642
  • 775
0

This should be easier with Git 2.35 (Q1 2022): the default merge message prepared by "git merge"(man) records the name of the current branch; the name can now be overridden with a new option to allow users to pretend a merge is made on a different branch.

See commit bd2bc94 (20 Dec 2021) by Junio C Hamano (gitster).
(Merged by Junio C Hamano -- gitster -- in commit bb14cfd, 05 Jan 2022)

merge: allow to pretend a merge is made into a different branch

When a series of patches for a topic-B depends on having topic-A, the workflow to prepare the topic-B branch would look like this:

    $ git checkout -b topic-B main
    $ git merge --no-ff --no-edit topic-A
    $ git am <mbox-for-topic-B

When topic-A gets updated, recreating the first merge and rebasing the rest of the topic-B, all on detached HEAD, is a useful technique.
After updating topic-A with its new round of patches:

(0) $ git checkout topic-B
(1) $ prev=$(git rev-parse 'HEAD^{/^Merge branch .topic-A. into}')
(2) $ git checkout --detach $prev^1
(3) $ git merge --no-ff --no-edit topic-A
(4) $ git rebase --onto HEAD $prev @{-1}^0
(5) $ git checkout -B @{-1}

This will:

  • (0) check out the current topic-B.
  • (1) find the previous merge of topic-A into topic-B.
  • (2) detach the HEAD to the parent of the previous merge.
  • (3) merge the updated topic-A to it.
  • (4) reapply the patches to rebuild the rest of topic-B.
  • (5) update topic-B with the result.

without contaminating the reflog of topic-B too much.

topic-B@{1} is the "logically previous" state before topic-A got updated, for example.
At (4), comparison (e.g. range-diff) between HEAD and @{-1} is a meaningful way to sanity check the result, and the same can be done at (5) by comparing topic-B and topic-B@{1}.

But there is one glitch.

The merge into the detached HEAD done in the step (3) above gives us "Merge branch 'topic-A' into HEAD", and does not say "into topic-B".

Teach the "--into-name=<branch>" option to "git merge"(man) and its underlying git fmt-merge-message, to pretend as if we were merging into <branch>, no matter what branch we are actually merging into, when they prepare the merge message.

git fmt-merge-msg now includes in its man page:

'git fmt-merge-msg' [-m ] [--into-name ] [--log[=] | --no-log]

--into-name <branch>

Prepare the merge message as if merging to the branch <branch>, instead of the name of the real branch to which the merge is made.

git merge now includes in its man page:

--into-name <branch>

Prepare the default merge message as if merging to the branch <branch>, instead of the name of the real branch to which the merge is made.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250