From: Junio C Hamano <gitster@pobox.com>
To: Sebastian Schuberth <sschuberth@gmail.com>
Cc: Git Mailing List <git@vger.kernel.org>,
Johannes Sixt <j6t@kdbg.org>,
sorganov@gmail.com
Subject: Re: [PATCH] docs: Clarify what git-rebase's "--preserve-merges" does
Date: Mon, 30 Mar 2015 10:23:20 -0700 [thread overview]
Message-ID: <xmqqfv8mxuuv.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <5519178A.6080408@gmail.com> (Sebastian Schuberth's message of "Mon, 30 Mar 2015 11:29:46 +0200")
Sebastian Schuberth <sschuberth@gmail.com> writes:
> So how about:
>
> [PATCH] docs: Clarify what git-rebase's "-p" / "--preserve-merges" does
>
> Ignoring a merge sounds like ignoring the changes a merge commit
> introduces altogether, as if the merge commit was skipped or dropped from
> history. But that is not what happens if "-p" is not specified.
Every time I read the above (which is essentially the same from your
first edition I think) I find the "ignoring the changes a merge
commit introduces altogether" and "as if the merge commit was
skipped" somehow contradicting with each other. If the latter were
"as if the side branch that was merged was skipped or dropped", I do
not see the room for such a misinterpretation.
That is, at least to me,
D---E---F
/ \
---A---B---C---G---H
the former, i.e. "the changes the merge G introdues", is "diff C G",
while "merge commit was skipped" would mean a history like this:
---A---B---C---D'--E'--F'--H'
And I think with "as if the side branch that was merged was
dropped", this misinterpretation will become impossible. It can
only mean this history:
---A---B---C---.---H'
> Instead, what happens is that the individual commits a merge commit
> introduces are replayed in order, and only any possible merge conflict
> resolutions or manual amendments to the merge commit are ignored. Get this
> straight in the docs.
>
> Also, do not say that merge commits are *tried* to be recreated. As that is
> true almost everywhere it is better left unsaid.
>
> Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
> ---
> Documentation/git-rebase.txt | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
> index d728030..47984e8 100644
> --- a/Documentation/git-rebase.txt
> +++ b/Documentation/git-rebase.txt
> @@ -362,7 +362,9 @@ default is `--no-fork-point`, otherwise the default is `--fork-point`.
>
> -p::
> --preserve-merges::
> - Instead of ignoring merges, try to recreate them.
> + Recreate merge commits instead of flattening the history by replaying
> + commits a merge commit introduces. Merge conflict resolutions or manual
> + amendments to merge commits are not preserved.
The patch text itself reads fine.
> +
> This uses the `--interactive` machinery internally, but combining it
> with the `--interactive` option explicitly is generally not a good
next prev parent reply other threads:[~2015-03-30 17:23 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-26 13:04 [PATCH] docs: Clarify what git-rebase's "--preserve-merges" does Sebastian Schuberth
2015-03-26 18:18 ` Junio C Hamano
2015-03-26 20:28 ` Sebastian Schuberth
2015-03-26 20:55 ` Junio C Hamano
2015-03-26 21:17 ` Sergey Organov
2015-03-26 21:41 ` Johannes Sixt
2015-03-31 9:13 ` Sergey Organov
2015-03-31 16:28 ` Junio C Hamano
2015-03-31 17:03 ` Sergey Organov
2015-03-31 17:04 ` Junio C Hamano
2015-04-01 11:27 ` Sergey Organov
2015-04-01 17:03 ` Junio C Hamano
2015-04-02 9:53 ` Sergey Organov
2015-03-30 9:29 ` Sebastian Schuberth
2015-03-30 17:23 ` Junio C Hamano [this message]
2015-03-30 19:42 ` Sebastian Schuberth
2015-03-30 19:58 ` Junio C Hamano
2015-03-30 20:23 ` Junio C Hamano
2015-03-30 21:09 ` Sebastian Schuberth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqfv8mxuuv.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=j6t@kdbg.org \
--cc=sorganov@gmail.com \
--cc=sschuberth@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.