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

Re: [PATCH] Re: Clarify documentation on the "ours" merge strategy.

From
Thomas Rast <trast@student.ethz.ch>
Date
Nov 11, 2009, 23:37 UTC
Message-ID
<200911120037.11901.trast@student.ethz.ch>
In-Reply-To
<20091111213049.GJ27518@vidovic>
Nicolas Sebrecht wrote:
Show 12 quoted lines
> The 11/11/09, Junio C Hamano wrote:
> > Thomas Rast <trast@student.ethz.ch> writes:
> > 
> > > ++
> > > +Because the sides in a rebase are swapped, using this strategy with
> > > +git-rebase is never a good idea.
> > 
> > Looking very good.
> 
> If this strategy is _never_ a good idea in this case, I tend to think
> that git should forbid this option, or at least, warn and refer to the
> documentation.

Then again, I'm not sure if resolve vs. recursive makes a difference in a rebase. Octopus is weird for a two-head merge, I'm not sure why the docs even talk about it. That would leave only subtree, which indeed has its uses. Should we add a note to that effect to git-rebase.txt? Like, say,

diff --git i/Documentation/git-rebase.txt w/Documentation/git-rebase.txt
index 33e0ef1..6e54a57 100644
--- i/Documentation/git-rebase.txt
+++ w/Documentation/git-rebase.txt
@@ -228,13 +228,19 @@ OPTIONS
 	Use merging strategies to rebase.  When the recursive (default) merge
 	strategy is used, this allows rebase to be aware of renames on the
 	upstream side.
++
+Note that in a rebase merge (hence merge conflict), the sides are
+swapped: "theirs" is the to-be-applied patch, and "ours" is the so-far
+rebased series, starting with <upstream>.
 
 -s <strategy>::
 --strategy=<strategy>::
 	Use the given merge strategy.
-	If there is no `-s` option, a built-in list of strategies
-	is used instead ('git-merge-recursive' when merging a single
-	head, 'git-merge-octopus' otherwise).  This implies --merge.
+	If there is no `-s` option 'git-merge-recursive' is used
+	instead.  This implies --merge.
++
+Due to the peculiarities of 'git-rebase' (see \--merge above) the only
+built-in strategy that is actually useful is 'subtree'.
 
 -q::
 --quiet::
diff --git i/Documentation/merge-strategies.txt w/Documentation/merge-strategies.txt
index 4365b7e..c1c3add 100644
--- i/Documentation/merge-strategies.txt
+++ w/Documentation/merge-strategies.txt
@@ -33,6 +33,9 @@ ours::
 	merge is always the current branch head.  It is meant to
 	be used to supersede old development history of side
 	branches.
++
+Because the sides in a rebase are swapped, using this strategy with
+'git-rebase' is never a good idea.
 
 subtree::
 	This is a modified recursive strategy. When merging trees A and
-- 
Thomas Rast
trast@{inf,student}.ethz.ch
Previous: Nicolas SebrechtNext: Junio C Hamano
Message 14 of 38 in “git pull --rebase and losing commits”
  1. Peter KreftingNov 2, 2009
  2. Thomas RastNov 2, 2009
  3. Nanako ShiraishiNov 2, 2009
  4. Björn SteinbrinkNov 2, 2009
  5. Peter KreftingNov 3, 2009
  6. Johannes SchindelinNov 3, 2009
  7. Peter KreftingNov 3, 2009
  8. Clarify documentation on the "ours" merge strategy.Peter Krefting, Nov 11, 2009
  9. BazNov 11, 2009
  10. Thomas RastNov 11, 2009
  11. BazNov 11, 2009
  12. Junio C HamanoNov 11, 2009
  13. Re: Clarify documentation on the "ours" merge strategy.Nicolas Sebrecht, Nov 11, 2009
  14. Thomas RastNov 11, 2009
  15. Junio C HamanoNov 12, 2009
  16. Peter KreftingNov 12, 2009
  17. Nanako ShiraishiNov 14, 2009
  18. Junio C HamanoNov 15, 2009
  19. Peter KreftingNov 16, 2009
  20. Björn SteinbrinkNov 12, 2009
  21. 0/3 Document and refuse rebase -s oursThomas Rast, Nov 15, 2009
  22. 1/3 Documentation: clarify 'ours' merge strategyThomas Rast, Nov 15, 2009
  23. 2/3 rebase docs: clarify --merge and --strategyThomas Rast, Nov 15, 2009
  24. Junio C HamanoNov 15, 2009
  25. Thomas RastNov 15, 2009
  26. 3/3 rebase: refuse to rebase with -s oursThomas Rast, Nov 15, 2009
  27. Sverre RabbelierNov 15, 2009
  28. Thomas RastNov 15, 2009
  29. Johannes SchindelinNov 16, 2009
  30. Junio C HamanoNov 16, 2009
  31. Johannes SchindelinNov 16, 2009
  32. Junio C HamanoNov 16, 2009
  33. Sverre RabbelierNov 16, 2009
  34. A Large Angry SCMNov 16, 2009
  35. Junio C HamanoNov 15, 2009
  36. Thomas RastNov 15, 2009
  37. Thomas RastNov 3, 2009
  38. Randal L. SchwartzNov 3, 2009

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.