All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Marc Branchaud <marcnarc@xiplink.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 2/5] fetch doc: update note on '+' in front of the refspec
Date: Fri, 30 May 2014 10:54:27 -0700	[thread overview]
Message-ID: <xmqqegzb9mp8.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <5388972E.2010008@xiplink.com> (Marc Branchaud's message of "Fri, 30 May 2014 10:35:26 -0400")

Marc Branchaud <marcnarc@xiplink.com> writes:

>> +When the remote branch you want to fetch is known to
>> +be rewound and rebased regularly, it is expected that
>> +the tip of it will not be descendant of the commit that
>> +used to be at its tip the last time you fetched it and
>> +stored in your remote-tracking branch.  You would want
>
> I think the second part of that last sentence might be clearer as
>
> 	it is expected that its new tip will not be a descendant of
> 	its previous tip (as stored in your remote-tracking branch
> 	the last time you fetched).

Yeah, that reads better.  Thanks.

>
> Then start the next sentence with
>
> 	In this case, you would want ....

I somehow find that "in this case" redundant, given that "for such
branches" already limits the scope of the suggestion.  I dunno.

>> +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]
>> 

  reply	other threads:[~2014-05-30 17:54 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-29 22:42 [PATCH 0/5] Documentation updates for 'git fetch' Junio C Hamano
2014-05-29 22:42 ` [PATCH 1/5] fetch doc: update introductory part for clarity Junio C Hamano
2014-05-30 14:35   ` Marc Branchaud
2014-05-30 17:52     ` Junio C Hamano
2014-05-30 19:13       ` Marc Branchaud
2014-05-30 21:27         ` Junio C Hamano
2014-06-02 15:21       ` [PATCH] fetch doc: Move FETCH_HEAD material, and add an example Marc Branchaud
2014-06-02 18:24         ` Junio C Hamano
2014-05-29 22:42 ` [PATCH 2/5] fetch doc: update note on '+' in front of the refspec Junio C Hamano
2014-05-30 14:35   ` Marc Branchaud
2014-05-30 17:54     ` Junio C Hamano [this message]
2014-06-02 15:37       ` Marc Branchaud
2014-05-29 22:42 ` [PATCH 3/5] fetch doc: remove notes on outdated "mixed layout" Junio C Hamano
2014-05-29 22:42 ` [PATCH 4/5] fetch doc: on pulling multiple refspecs Junio C Hamano
2014-05-29 22:42 ` [PATCH 5/5] fetch doc: update refspec format description Junio C Hamano

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=xmqqegzb9mp8.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=marcnarc@xiplink.com \
    /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.