2005-11-01 21:45:55 +01:00
|
|
|
git-fmt-merge-msg(1)
|
|
|
|
|
====================
|
|
|
|
|
|
|
|
|
|
NAME
|
|
|
|
|
----
|
|
|
|
|
git-fmt-merge-msg - Produce a merge commit message
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
|
--------
|
2007-05-18 15:39:33 +02:00
|
|
|
[verse]
|
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:
$ 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>
2021-12-20 23:53:43 +01:00
|
|
|
'git fmt-merge-msg' [-m <message>] [--into-name <branch>] [--log[=<n>] | --no-log]
|
2010-09-08 19:59:54 +02:00
|
|
|
'git fmt-merge-msg' [-m <message>] [--log[=<n>] | --no-log] -F <file>
|
2005-11-01 21:45:55 +01:00
|
|
|
|
|
|
|
|
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
|
2010-01-10 00:33:00 +01:00
|
|
|
passed as the '<merge-message>' argument of 'git merge'.
|
2005-11-01 21:45:55 +01:00
|
|
|
|
2009-10-09 12:16:15 +02:00
|
|
|
This command is intended mostly for internal use by scripts
|
|
|
|
|
automatically invoking 'git merge'.
|
2005-11-01 21:45:55 +01:00
|
|
|
|
2007-04-27 06:58:57 +02:00
|
|
|
OPTIONS
|
|
|
|
|
-------
|
|
|
|
|
|
2010-09-08 19:59:54 +02:00
|
|
|
--log[=<n>]::
|
2007-04-27 06:58:57 +02:00
|
|
|
In addition to branch names, populate the log message with
|
|
|
|
|
one-line descriptions from the actual commits that are being
|
2010-09-08 19:59:54 +02:00
|
|
|
merged. At most <n> commits from each merge parent will be
|
|
|
|
|
used (20 if <n> is omitted). This overrides the `merge.log`
|
|
|
|
|
configuration variable.
|
2007-04-27 06:58:57 +02:00
|
|
|
|
2008-04-06 03:23:45 +02:00
|
|
|
--no-log::
|
2007-04-27 06:58:57 +02:00
|
|
|
Do not list one-line descriptions from the actual commits being
|
|
|
|
|
merged.
|
|
|
|
|
|
2013-05-09 03:16:55 +02:00
|
|
|
--[no-]summary::
|
2008-04-06 03:23:45 +02:00
|
|
|
Synonyms to --log and --no-log; these are deprecated and will be
|
|
|
|
|
removed in the future.
|
|
|
|
|
|
2010-08-18 01:00:34 +02:00
|
|
|
-m <message>::
|
|
|
|
|
--message <message>::
|
|
|
|
|
Use <message> instead of the branch names for the first line
|
|
|
|
|
of the log message. For use with `--log`.
|
|
|
|
|
|
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:
$ 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>
2021-12-20 23:53:43 +01:00
|
|
|
--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.
|
|
|
|
|
|
2008-06-08 03:36:09 +02:00
|
|
|
-F <file>::
|
|
|
|
|
--file <file>::
|
2007-04-27 06:58:57 +02:00
|
|
|
Take the list of merged objects from <file> instead of
|
|
|
|
|
stdin.
|
|
|
|
|
|
|
|
|
|
CONFIGURATION
|
|
|
|
|
-------------
|
2018-10-27 08:22:57 +02:00
|
|
|
include::config/fmt-merge-msg.txt[]
|
2005-11-01 21:45:55 +01:00
|
|
|
|
2008-04-06 03:23:45 +02:00
|
|
|
merge.summary::
|
|
|
|
|
Synonym to `merge.log`; this is deprecated and will be removed in
|
|
|
|
|
the future.
|
|
|
|
|
|
2018-04-30 17:35:33 +02:00
|
|
|
EXAMPLES
|
|
|
|
|
--------
|
usage: do not insist that standard input must come from a file
The synopsys text and the usage string of subcommands that read list
of things from the standard input are often shown like this:
git gostak [--distim] < <list-of-doshes>
This is problematic in a number of ways:
* The way to use these commands is more often to feed them the
output from another command, not feed them from a file.
* Manual pages outside Git, commands that operate on the data read
from the standard input, e.g "sort", "grep", "sed", etc., are not
described with such a "< redirection-from-file" in their synopsys
text. Our doing so introduces inconsistency.
* We do not insist on where the output should go, by saying
git gostak [--distim] < <list-of-doshes> > <output>
* As it is our convention to enclose placeholders inside <braket>,
the redirection operator followed by a placeholder filename
becomes very hard to read, both in the documentation and in the
help text.
Let's clean them all up, after making sure that the documentation
clearly describes the modes that take information from the standard
input and what kind of things are expected on the input.
[jc: stole example for fmt-merge-msg from Jonathan]
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-16 20:27:42 +02:00
|
|
|
|
2016-10-28 12:01:26 +02:00
|
|
|
---------
|
usage: do not insist that standard input must come from a file
The synopsys text and the usage string of subcommands that read list
of things from the standard input are often shown like this:
git gostak [--distim] < <list-of-doshes>
This is problematic in a number of ways:
* The way to use these commands is more often to feed them the
output from another command, not feed them from a file.
* Manual pages outside Git, commands that operate on the data read
from the standard input, e.g "sort", "grep", "sed", etc., are not
described with such a "< redirection-from-file" in their synopsys
text. Our doing so introduces inconsistency.
* We do not insist on where the output should go, by saying
git gostak [--distim] < <list-of-doshes> > <output>
* As it is our convention to enclose placeholders inside <braket>,
the redirection operator followed by a placeholder filename
becomes very hard to read, both in the documentation and in the
help text.
Let's clean them all up, after making sure that the documentation
clearly describes the modes that take information from the standard
input and what kind of things are expected on the input.
[jc: stole example for fmt-merge-msg from Jonathan]
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-16 20:27:42 +02:00
|
|
|
$ git fetch origin master
|
|
|
|
|
$ git fmt-merge-msg --log <$GIT_DIR/FETCH_HEAD
|
2016-10-28 12:01:26 +02:00
|
|
|
---------
|
usage: do not insist that standard input must come from a file
The synopsys text and the usage string of subcommands that read list
of things from the standard input are often shown like this:
git gostak [--distim] < <list-of-doshes>
This is problematic in a number of ways:
* The way to use these commands is more often to feed them the
output from another command, not feed them from a file.
* Manual pages outside Git, commands that operate on the data read
from the standard input, e.g "sort", "grep", "sed", etc., are not
described with such a "< redirection-from-file" in their synopsys
text. Our doing so introduces inconsistency.
* We do not insist on where the output should go, by saying
git gostak [--distim] < <list-of-doshes> > <output>
* As it is our convention to enclose placeholders inside <braket>,
the redirection operator followed by a placeholder filename
becomes very hard to read, both in the documentation and in the
help text.
Let's clean them all up, after making sure that the documentation
clearly describes the modes that take information from the standard
input and what kind of things are expected on the input.
[jc: stole example for fmt-merge-msg from Jonathan]
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-10-16 20:27:42 +02:00
|
|
|
|
|
|
|
|
Print a log message describing a merge of the "master" branch from
|
|
|
|
|
the "origin" remote.
|
|
|
|
|
|
|
|
|
|
|
2005-11-01 21:45:55 +01:00
|
|
|
SEE ALSO
|
|
|
|
|
--------
|
2007-12-29 07:20:38 +01:00
|
|
|
linkgit:git-merge[1]
|
2005-11-01 21:45:55 +01:00
|
|
|
|
|
|
|
|
GIT
|
|
|
|
|
---
|
2008-06-06 09:07:32 +02:00
|
|
|
Part of the linkgit:git[1] suite
|