All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: git@vger.kernel.org
Subject: [PATCH v2 3/9] fetch doc: update note on '+' in front of the refspec
Date: Tue,  3 Jun 2014 15:16:26 -0700	[thread overview]
Message-ID: <1401833792-2486-4-git-send-email-gitster@pobox.com> (raw)
In-Reply-To: <1401833792-2486-1-git-send-email-gitster@pobox.com>

While it is not *wrong* per-se to say that pulling a rewound/rebased
branch will lead to an unnecessary merge conflict, that is not what
the leading "+" sign to allow non-fast-forward update of remote-tracking
branch is at all.

Helped-by: Marc Branchaud <marcnarc@xiplink.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
 Documentation/pull-fetch-param.txt | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/Documentation/pull-fetch-param.txt b/Documentation/pull-fetch-param.txt
index 18cffc2..41474c5 100644
--- a/Documentation/pull-fetch-param.txt
+++ b/Documentation/pull-fetch-param.txt
@@ -24,15 +24,15 @@ is updated even if it does not result in a fast-forward
 update.
 +
 [NOTE]
-If the remote branch from which you want to pull is
-modified in non-linear ways such as being rewound and
-rebased frequently, then a pull will attempt a merge with
-an older version of itself, likely conflict, and fail.
-It is under these conditions that you would want to use
-the `+` sign to indicate non-fast-forward updates will
-be needed.  There is currently no easy way to determine
-or declare that a branch will be made available in a
-repository with this behavior; the pulling user simply
+When the remote branch you want to fetch is known to
+be rewound and rebased regularly, it is expected that
+its new tip will not be descendant of its previous tip
+(as stored in your remote-tracking branch the last time
+you fetched).  You would want
+to use the `+` sign to indicate non-fast-forward updates
+will be needed for such branches.  There is no way to
+determine or declare that a branch will be made available
+in a repository with this behavior; the pulling user simply
 must know this is the expected usage pattern for a branch.
 +
 [NOTE]
-- 
2.0.0-511-g1433423

  parent reply	other threads:[~2014-06-03 22:17 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-03 22:16 [PATCH v2 0/9] Clarify two uses of remote.*.fetch Junio C Hamano
2014-06-03 22:16 ` [PATCH v2 1/9] fetch doc: update introductory part for clarity Junio C Hamano
2014-06-03 22:16 ` [PATCH v2 2/9] fetch doc: move FETCH_HEAD material lower and add an example Junio C Hamano
2014-06-03 22:16 ` Junio C Hamano [this message]
2014-06-18  7:56   ` [PATCH v2 3/9] fetch doc: update note on '+' in front of the refspec Michael Haggerty
2014-06-03 22:16 ` [PATCH v2 4/9] fetch doc: remove notes on outdated "mixed layout" Junio C Hamano
2014-06-03 22:16 ` [PATCH v2 5/9] fetch doc: on pulling multiple refspecs Junio C Hamano
2014-06-04 14:44   ` Marc Branchaud
2014-06-03 22:16 ` [PATCH v2 6/9] fetch doc: update refspec format description Junio C Hamano
2014-06-03 22:16 ` [PATCH v2 7/9] fetch doc: remove "short-cut" section Junio C Hamano
2014-06-04 14:46   ` Marc Branchaud
2014-06-03 22:16 ` [PATCH v2 8/9] fetch doc: add a section on configured remote-tracking branches Junio C Hamano
2014-06-04 14:55   ` Marc Branchaud
2014-06-04 22:17     ` Junio C Hamano
2014-06-05 15:29       ` Marc Branchaud
2014-06-05 15:40         ` [PATCH] docs: Explain the purpose of fetch's and pull's <refspec> parameter Marc Branchaud
2014-06-05 22:12           ` Junio C Hamano
2014-06-11 14:24             ` Marc Branchaud
2014-06-03 22:16 ` [PATCH v2 9/9] fetch: allow explicit --refmap to override configuration Junio C Hamano
2014-06-04 15:01   ` Marc Branchaud
2014-06-04 22:28     ` Junio C Hamano
2014-06-05 15:45       ` Marc Branchaud
2014-06-05 18:36         ` Junio C Hamano
2014-06-18 12:21           ` Michael Haggerty

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=1401833792-2486-4-git-send-email-gitster@pobox.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.