2006-08-02 21:52:00 +00:00
|
|
|
#include "builtin.h"
|
2017-06-14 18:07:36 +00:00
|
|
|
#include "config.h"
|
2011-10-07 06:12:09 +00:00
|
|
|
#include "fmt-merge-msg.h"
|
2023-03-21 06:25:54 +00:00
|
|
|
#include "gettext.h"
|
2020-03-24 01:07:51 +00:00
|
|
|
#include "parse-options.h"
|
2023-03-21 06:26:01 +00:00
|
|
|
#include "wrapper.h"
|
2006-07-03 15:18:43 +00:00
|
|
|
|
2008-10-02 12:59:18 +00:00
|
|
|
static const char * const fmt_merge_msg_usage[] = {
|
2015-01-13 07:44:47 +00:00
|
|
|
N_("git fmt-merge-msg [-m <message>] [--log[=<n>] | --no-log] [--file <file>]"),
|
2008-10-02 12:59:18 +00:00
|
|
|
NULL
|
|
|
|
|
};
|
2006-07-03 15:18:43 +00:00
|
|
|
|
2008-06-27 16:21:59 +00:00
|
|
|
int cmd_fmt_merge_msg(int argc, const char **argv, const char *prefix)
|
|
|
|
|
{
|
2008-10-02 12:59:18 +00:00
|
|
|
const char *inpath = NULL;
|
2010-08-17 23:00:34 +00:00
|
|
|
const char *message = NULL;
|
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 22:53:43 +00:00
|
|
|
char *into_name = NULL;
|
2011-10-07 06:12:09 +00:00
|
|
|
int shortlog_len = -1;
|
2008-10-02 12:59:18 +00:00
|
|
|
struct option options[] = {
|
2012-08-20 12:32:10 +00:00
|
|
|
{ OPTION_INTEGER, 0, "log", &shortlog_len, N_("n"),
|
|
|
|
|
N_("populate log with at most <n> entries from shortlog"),
|
2010-09-08 17:59:54 +00:00
|
|
|
PARSE_OPT_OPTARG, NULL, DEFAULT_MERGE_LOG_LEN },
|
2012-08-20 12:32:10 +00:00
|
|
|
{ OPTION_INTEGER, 0, "summary", &shortlog_len, N_("n"),
|
|
|
|
|
N_("alias for --log (deprecated)"),
|
2010-09-08 17:59:54 +00:00
|
|
|
PARSE_OPT_OPTARG | PARSE_OPT_HIDDEN, NULL,
|
|
|
|
|
DEFAULT_MERGE_LOG_LEN },
|
2012-08-20 12:32:10 +00:00
|
|
|
OPT_STRING('m', "message", &message, N_("text"),
|
|
|
|
|
N_("use <text> as start of message")),
|
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 22:53:43 +00:00
|
|
|
OPT_STRING(0, "into-name", &into_name, N_("name"),
|
|
|
|
|
N_("use <name> instead of the real target branch")),
|
2012-08-20 12:32:10 +00:00
|
|
|
OPT_FILENAME('F', "file", &inpath, N_("file to read from")),
|
2008-10-02 12:59:18 +00:00
|
|
|
OPT_END()
|
|
|
|
|
};
|
|
|
|
|
|
2008-06-27 16:21:59 +00:00
|
|
|
FILE *in = stdin;
|
2008-10-09 19:12:12 +00:00
|
|
|
struct strbuf input = STRBUF_INIT, output = STRBUF_INIT;
|
2008-06-27 16:21:59 +00:00
|
|
|
int ret;
|
2011-11-05 00:35:42 +00:00
|
|
|
struct fmt_merge_msg_opts opts;
|
2008-06-27 16:21:59 +00:00
|
|
|
|
|
|
|
|
git_config(fmt_merge_msg_config, NULL);
|
2009-05-23 18:53:12 +00:00
|
|
|
argc = parse_options(argc, argv, prefix, options, fmt_merge_msg_usage,
|
|
|
|
|
0);
|
2008-10-02 12:59:18 +00:00
|
|
|
if (argc > 0)
|
|
|
|
|
usage_with_options(fmt_merge_msg_usage, options);
|
2011-10-07 06:12:09 +00:00
|
|
|
if (shortlog_len < 0)
|
|
|
|
|
shortlog_len = (merge_log_config > 0) ? merge_log_config : 0;
|
2008-10-02 12:59:18 +00:00
|
|
|
|
|
|
|
|
if (inpath && strcmp(inpath, "-")) {
|
|
|
|
|
in = fopen(inpath, "r");
|
|
|
|
|
if (!in)
|
2009-06-27 15:58:47 +00:00
|
|
|
die_errno("cannot open '%s'", inpath);
|
2008-06-27 16:21:59 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (strbuf_read(&input, fileno(in), 0) < 0)
|
2009-06-27 15:58:46 +00:00
|
|
|
die_errno("could not read input file");
|
2010-09-08 17:59:53 +00:00
|
|
|
|
|
|
|
|
if (message)
|
2010-08-17 23:00:34 +00:00
|
|
|
strbuf_addstr(&output, message);
|
2010-09-08 17:59:53 +00:00
|
|
|
|
2011-11-05 00:35:42 +00:00
|
|
|
memset(&opts, 0, sizeof(opts));
|
|
|
|
|
opts.add_title = !message;
|
2012-12-28 23:29:31 +00:00
|
|
|
opts.credit_people = 1;
|
2011-11-05 00:35:42 +00:00
|
|
|
opts.shortlog_len = shortlog_len;
|
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 22:53:43 +00:00
|
|
|
opts.into_name = into_name;
|
2011-11-05 00:35:42 +00:00
|
|
|
|
|
|
|
|
ret = fmt_merge_msg(&input, &output, &opts);
|
2008-06-27 16:21:59 +00:00
|
|
|
if (ret)
|
|
|
|
|
return ret;
|
2008-10-02 12:59:18 +00:00
|
|
|
write_in_full(STDOUT_FILENO, output.buf, output.len);
|
2006-07-03 15:18:43 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|