From: Baz <brian.ewins@gmail.com>
To: Peter Krefting <peter@softwolves.pp.se>
Cc: "Git Mailing List" <git@vger.kernel.org>,
"Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
"Thomas Rast" <trast@student.ethz.ch>,
"Björn Steinbrink" <B.Steinbrink@gmx.de>
Subject: Re: [PATCH] Clarify documentation on the "ours" merge strategy.
Date: Wed, 11 Nov 2009 15:13:52 +0000 [thread overview]
Message-ID: <2faad3050911110713y4e33c7d2h21ad42efe4fd70b3@mail.gmail.com> (raw)
In-Reply-To: <200911111411.nABEBfox031023@ds9.cixit.se>
2009/11/11 Peter Krefting <peter@softwolves.pp.se>:
> 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
> 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
>
next prev parent reply other threads:[~2009-11-11 15:14 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-02 12:26 git pull --rebase and losing commits Peter Krefting
2009-11-02 15:04 ` Thomas Rast
2009-11-02 21:34 ` Nanako Shiraishi
2009-11-02 15:10 ` Björn Steinbrink
2009-11-03 7:01 ` Peter Krefting
2009-11-03 9:52 ` Johannes Schindelin
2009-11-03 10:12 ` Peter Krefting
2009-11-11 14:03 ` [PATCH] Clarify documentation on the "ours" merge strategy Peter Krefting
2009-11-11 15:13 ` Baz [this message]
2009-11-11 20:35 ` Thomas Rast
2009-11-11 20:54 ` Baz
2009-11-11 21:02 ` Junio C Hamano
2009-11-11 21:30 ` [PATCH] " Nicolas Sebrecht
2009-11-11 23:37 ` Thomas Rast
2009-11-12 7:55 ` Junio C Hamano
2009-11-12 9:41 ` Peter Krefting
2009-11-14 2:12 ` Nanako Shiraishi
2009-11-15 9:10 ` Junio C Hamano
2009-11-16 8:20 ` Peter Krefting
2009-11-12 9:55 ` Björn Steinbrink
2009-11-15 18:25 ` [PATCH 0/3] Document and refuse rebase -s ours Thomas Rast
2009-11-15 18:25 ` [PATCH 1/3] Documentation: clarify 'ours' merge strategy Thomas Rast
2009-11-15 18:25 ` [PATCH 2/3] rebase docs: clarify --merge and --strategy Thomas Rast
2009-11-15 21:05 ` Junio C Hamano
2009-11-15 21:11 ` Thomas Rast
2009-11-15 18:25 ` [PATCH 3/3] rebase: refuse to rebase with -s ours Thomas Rast
2009-11-15 18:39 ` Sverre Rabbelier
2009-11-15 18:44 ` Thomas Rast
2009-11-16 12:35 ` Johannes Schindelin
2009-11-16 19:57 ` Junio C Hamano
2009-11-16 21:25 ` Johannes Schindelin
2009-11-16 21:45 ` Junio C Hamano
2009-11-16 22:04 ` Sverre Rabbelier
2009-11-16 23:04 ` A Large Angry SCM
2009-11-15 21:04 ` [PATCH 0/3] Document and refuse rebase " Junio C Hamano
2009-11-15 21:13 ` Thomas Rast
2009-11-03 10:12 ` git pull --rebase and losing commits Thomas Rast
2009-11-03 4:27 ` Randal L. Schwartz
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=2faad3050911110713y4e33c7d2h21ad42efe4fd70b3@mail.gmail.com \
--to=brian.ewins@gmail.com \
--cc=B.Steinbrink@gmx.de \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
--cc=peter@softwolves.pp.se \
--cc=trast@student.ethz.ch \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).