git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] docs: Clarify what git-rebase's "--preserve-merges" does

From
Sebastian Schuberth <sschuberth@gmail.com>
Date
Mar 30, 2015, 09:29 UTC
Message-ID
<5519178A.6080408@gmail.com>
In-Reply-To
<xmqqd23vzkon.fsf@gitster.dls.corp.google.com>
On 3/26/2015 19:18, Junio C Hamano wrote:
> Although I fully agree that the new text is better than the original,
> I think the new text fails to point out one major aspect by not
> mentioning "linear" or "flatten" anywhere.  The point of "git rebase"
> without "-p" is not just to replay but to flatten
I think it's a bit odd to say that "-p" does not flatten if the whole current rebase docs do not use the terms flattening / linearize at all. If we say that that "-p" does not flatten, we should say that a "standard" rebase wihtout "-p" does. I plan to send a patch for that later.
> 	Instead of flattening the history by replaying each
> 	non-merge commit to be rebased, preserve the shape of the
> 	rebased history by recreating merge commits as well.
Personally, I like "positive logic" better here, i.e. start with saying what the option does, not what it does not do.
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.

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.
 +
 This uses the `--interactive` machinery internally, but combining it
 with the `--interactive` option explicitly is generally not a good
-- 
1.9.5.msysgit.1
Previous: Sergey OrganovNext: Junio C Hamano
Message 14 of 19 in “docs: Clarify what git-rebase's "--preserve-merges" does”
  1. docs: Clarify what git-rebase's "--preserve-merges" doesSebastian Schuberth, Mar 26, 2015
  2. Junio C HamanoMar 26, 2015
  3. Sebastian SchuberthMar 26, 2015
  4. Junio C HamanoMar 26, 2015
  5. Sergey OrganovMar 26, 2015
  6. Johannes SixtMar 26, 2015
  7. Sergey OrganovMar 31, 2015
  8. Junio C HamanoMar 31, 2015
  9. Sergey OrganovMar 31, 2015
  10. Junio C HamanoMar 31, 2015
  11. Sergey OrganovApr 1, 2015
  12. Junio C HamanoApr 1, 2015
  13. Sergey OrganovApr 2, 2015
  14. Sebastian SchuberthMar 30, 2015
  15. Junio C HamanoMar 30, 2015
  16. Sebastian SchuberthMar 30, 2015
  17. Junio C HamanoMar 30, 2015
  18. Junio C HamanoMar 30, 2015
  19. Sebastian SchuberthMar 30, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.