bd2bc94252
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:
$ git checkout topic-B
$ prev=$(git rev-parse 'HEAD^{/^Merge branch .topic-A. into}')
$ git checkout --detach $prev^1
$ git merge --no-ff --no-edit topic-A
$ git rebase --onto HEAD $prev @{-1}^0
$ 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" 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. The pretend name honors the
usual "into <target>" suppression mechanism, which can be seen in
the tests added here.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
83 lines
1.9 KiB
Plaintext
83 lines
1.9 KiB
Plaintext
git-fmt-merge-msg(1)
|
|
====================
|
|
|
|
NAME
|
|
----
|
|
git-fmt-merge-msg - Produce a merge commit message
|
|
|
|
|
|
SYNOPSIS
|
|
--------
|
|
[verse]
|
|
'git fmt-merge-msg' [-m <message>] [--into-name <branch>] [--log[=<n>] | --no-log]
|
|
'git fmt-merge-msg' [-m <message>] [--log[=<n>] | --no-log] -F <file>
|
|
|
|
DESCRIPTION
|
|
-----------
|
|
Takes the list of merged objects on stdin and produces a suitable
|
|
commit message to be used for the merge commit, usually to be
|
|
passed as the '<merge-message>' argument of 'git merge'.
|
|
|
|
This command is intended mostly for internal use by scripts
|
|
automatically invoking 'git merge'.
|
|
|
|
OPTIONS
|
|
-------
|
|
|
|
--log[=<n>]::
|
|
In addition to branch names, populate the log message with
|
|
one-line descriptions from the actual commits that are being
|
|
merged. At most <n> commits from each merge parent will be
|
|
used (20 if <n> is omitted). This overrides the `merge.log`
|
|
configuration variable.
|
|
|
|
--no-log::
|
|
Do not list one-line descriptions from the actual commits being
|
|
merged.
|
|
|
|
--[no-]summary::
|
|
Synonyms to --log and --no-log; these are deprecated and will be
|
|
removed in the future.
|
|
|
|
-m <message>::
|
|
--message <message>::
|
|
Use <message> instead of the branch names for the first line
|
|
of the log message. For use with `--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.
|
|
|
|
-F <file>::
|
|
--file <file>::
|
|
Take the list of merged objects from <file> instead of
|
|
stdin.
|
|
|
|
CONFIGURATION
|
|
-------------
|
|
include::config/fmt-merge-msg.txt[]
|
|
|
|
merge.summary::
|
|
Synonym to `merge.log`; this is deprecated and will be removed in
|
|
the future.
|
|
|
|
EXAMPLES
|
|
--------
|
|
|
|
---------
|
|
$ git fetch origin master
|
|
$ git fmt-merge-msg --log <$GIT_DIR/FETCH_HEAD
|
|
---------
|
|
|
|
Print a log message describing a merge of the "master" branch from
|
|
the "origin" remote.
|
|
|
|
|
|
SEE ALSO
|
|
--------
|
|
linkgit:git-merge[1]
|
|
|
|
GIT
|
|
---
|
|
Part of the linkgit:git[1] suite
|