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

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

From
Baz <brian.ewins@gmail.com>
Date
Nov 11, 2009, 15:13 UTC
Message-ID
<2faad3050911110713y4e33c7d2h21ad42efe4fd70b3@mail.gmail.com>
In-Reply-To
<200911111411.nABEBfox031023@ds9.cixit.se>
2009/11/11 Peter Krefting <peter@softwolves.pp.se>:
Show 23 quoted lines
> Make it clear that the merge strategy will discard all changes made to
> the branch being merged, and not just avoid creating merge conflicts.
> ---
>  Documentation/merge-strategies.txt |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
>
>> If you want to use any merge strategy, you must understand what it does
>> first.
>
> Indeed. Perhaps this clarification will help the next poor soul that tries
> doing what I tried?
>
> diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt
> index 4365b7e..a340dc9 100644
> --- a/Documentation/merge-strategies.txt
> +++ b/Documentation/merge-strategies.txt
> @@ -30,7 +30,8 @@ octopus::
>
>  ours::
>        This resolves any number of heads, but the result of the
> -       merge is always the current branch head.  It is meant to
> +       merge is always the current branch head, discarding any
> +       changes on the merged branch.  It is meant to

I think part of the problem is that it is unclear what the "current branch head" means when used in a rebase, and hence when this text is included in the help for git-rebase and git-pull. This flipped behaviour is surprising given the natural meaning of 'ours', or 'current branch', particularly for git pull:

git pull -s ours - discards changes in remote branch, keeps changes in current branch git pull --rebase -s ours - discards changes in current branch, keeps changes in remote branch

Perhaps something more in the way of an explicit warning?
ours::
         This resolves any number of heads, but the result of the
         merge is always the current branch head, discarding any
         changes on the merged branch.  It is meant to
         be used to supersede old development history of side
         branches. Note that when rebasing, the branch you are
         rebasing onto is the "current branch head", and using this
         strategy will lose all of your changes - unlikely to be what
         you wanted to do.
-Baz
Show 11 quoted lines
>        be used to supersede old development history of side
>        branches.
>
> --
> 1.6.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
Previous: Peter KreftingNext: Thomas Rast
Message 9 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.