git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Bagas Sanjaya <bagasdotme@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] revisions(7): clarify that most commands take a single revision range
Date: Thu, 20 May 2021 14:02:25 +0900	[thread overview]
Message-ID: <xmqqcztmuhem.fsf@gitster.g> (raw)
In-Reply-To: <xmqqh7iyuhlp.fsf@gitster.g> (Junio C. Hamano's message of "Thu, 20 May 2021 13:58:10 +0900")

Junio C Hamano <gitster@pobox.com> writes:

> Bagas Sanjaya <bagasdotme@gmail.com> writes:
>
>> On 18/05/21 18.17, Junio C Hamano wrote:
>>> ...
>>> +In other words, writing two "two-dot range notation" next to each
>>> +other, e.g.
>>> +
>>> +    $ git log A..B C..D
>>> +
>>> +does *not* specify two revision ranges for most commands.  Instead
>>> +it will name a single connected set of commits, i.e. those that are
>>> +reachable from either B or D but are reachable from neither A or C.
>>> +In a linear history like this:
>>> +
>>> +    ---A---B---o---o---C---D
>>> +
>>
>> So "git log A..B C..D" is same as "A..D", right?
>
> A..B C..D is equivalent to ^A ^C B D, and in order to be part of the
> set it represents, a commit must not be reachable from A, must not
> be reachable from C, and must be reachable from B or D.
>
> In the picture, A, B and two o's are all reachable from C, therefore
> are not part of the set A..B C..D represents.  Neither is C, as it
> is reachable from C.  That leaves only D in the resulting range.
>
> A..D is a set of connected five commits, B o o C D in the above
> picture.
>
> So, no.
>
> The confusion we often see goes more like "The set A..B contains B
> (and nothing else), and C..D contains D (and nothing else), hence
> 'git log A..B C..D' would show B and D".  But that is not what
> happens because "git log" (like most other commands) takes just a
> "range" that is "A..B C..D", which is a set of connected commits
> each of whose member is reachable from one of the "positive"
> endpoints (like B and D) and is not reachable from any of the
> "negative" endpoints (like A and C).

Well, apparently the proposed text may have failed to educate you
about what a "revision range" is and how it works, so it is not good
enough, so I'll postpone merging the change down further and see if
somebody else can come up with a better description.

Thanks.

  reply	other threads:[~2021-05-20  5:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-18 11:17 Junio C Hamano
2021-05-20  2:27 ` Bagas Sanjaya
2021-05-20  4:58   ` Junio C Hamano
2021-05-20  5:02     ` Junio C Hamano [this message]
2021-05-20  5:26       ` Bagas Sanjaya
2021-05-20 16:45       ` Elijah Newren
2021-05-20 16:53         ` Eric Sunshine
2021-05-20 16:40   ` Elijah Newren
2021-05-21 19:19 ` Felipe Contreras

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=xmqqcztmuhem.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=bagasdotme@gmail.com \
    --cc=git@vger.kernel.org \
    --subject='Re: [PATCH] revisions(7): clarify that most commands take a single revision range' \
    /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

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).