diff options
| author | Junio C Hamano <gitster@pobox.com> | 2021-12-20 14:53:43 -0800 |
|---|---|---|
| committer | Junio C Hamano <gitster@pobox.com> | 2021-12-20 14:55:02 -0800 |
| commit | bd2bc94252a47443e19d366f8cc9626d4f92df7a (patch) | |
| tree | 692b1b4563512d4bd54faab15649282f1bf2a31d /Documentation/git-merge.txt | |
| parent | cd3e606211bb1cf8bc57f7d76bab98cc17a150bc (diff) | |
| download | git-bd2bc94252a47443e19d366f8cc9626d4f92df7a.tar.gz | |
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>
Diffstat (limited to 'Documentation/git-merge.txt')
| -rw-r--r-- | Documentation/git-merge.txt | 8 |
1 files changed, 7 insertions, 1 deletions
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt index e4f3352eb5..ed0990621f 100644 --- a/Documentation/git-merge.txt +++ b/Documentation/git-merge.txt @@ -12,7 +12,8 @@ SYNOPSIS 'git merge' [-n] [--stat] [--no-commit] [--squash] [--[no-]edit] [--no-verify] [-s <strategy>] [-X <strategy-option>] [-S[<keyid>]] [--[no-]allow-unrelated-histories] - [--[no-]rerere-autoupdate] [-m <msg>] [-F <file>] [<commit>...] + [--[no-]rerere-autoupdate] [-m <msg>] [-F <file>] + [--into-name <branch>] [<commit>...] 'git merge' (--continue | --abort | --quit) DESCRIPTION @@ -76,6 +77,11 @@ The 'git fmt-merge-msg' command can be used to give a good default for automated 'git merge' invocations. The automated message can include the branch description. +--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. + -F <file>:: --file=<file>:: Read the commit message to be used for the merge commit (in |