git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thomas Rast <trast@student.ethz.ch>
To: <git@vger.kernel.org>
Cc: "Nicolas Sebrecht" <nicolas.s.dev@gmx.fr>,
	Baz <brian.ewins@gmail.com>,
	"Peter Krefting" <peter@softwolves.pp.se>,
	"Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
	"Björn Steinbrink" <B.Steinbrink@gmx.de>
Subject: [PATCH 1/3] Documentation: clarify 'ours' merge strategy
Date: Sun, 15 Nov 2009 19:25:30 +0100	[thread overview]
Message-ID: <234d8bfd14ef0a90d4df16e00864058ff8ac8d38.1258309432.git.trast@student.ethz.ch> (raw)
In-Reply-To: <cover.1258309432.git.trast@student.ethz.ch>

Make it clear in the docs that the merge takes the tree of HEAD and
ignores everything in the other branches.  This should hopefully clear
up confusion, usually caused by the user looking for a strategy that
resolves all conflict hunks in favour of HEAD (which is completely
different and currently not supported).

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
 Documentation/merge-strategies.txt |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/merge-strategies.txt b/Documentation/merge-strategies.txt
index 4365b7e..42910a3 100644
--- a/Documentation/merge-strategies.txt
+++ b/Documentation/merge-strategies.txt
@@ -29,8 +29,9 @@ octopus::
 	pulling or merging more than one branch.
 
 ours::
-	This resolves any number of heads, but the result of the
-	merge is always the current branch head.  It is meant to
+	This resolves any number of heads, but the resulting tree of the
+	merge is always that of the current branch head, effectively
+	ignoring all changes from all other branches.  It is meant to
 	be used to supersede old development history of side
 	branches.
 
-- 
1.6.5.2.420.gf6c057.dirty

  reply	other threads:[~2009-11-15 18:26 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
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                       ` Thomas Rast [this message]
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=234d8bfd14ef0a90d4df16e00864058ff8ac8d38.1258309432.git.trast@student.ethz.ch \
    --to=trast@student.ethz.ch \
    --cc=B.Steinbrink@gmx.de \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=brian.ewins@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=nicolas.s.dev@gmx.fr \
    --cc=peter@softwolves.pp.se \
    /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).