archive mirror
 help / color / mirror / Atom feed
From: Bagas Sanjaya <>
To: Junio C Hamano <>
Subject: Re: [PATCH] revisions(7): clarify that most commands take a single revision range
Date: Thu, 20 May 2021 12:26:36 +0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <xmqqcztmuhem.fsf@gitster.g>

On 20/05/21 12.02, Junio C Hamano wrote:
>> 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.

 From Pro Git book [1]:
> The most common range specification is the double-dot syntax. This basically asks Git to resolve a range of commits that are reachable from one commit but aren’t reachable from another.
> Say you want to see what is in your experiment branch that hasn’t yet been merged into your master branch. You can ask Git to show you a log of just those commits with master..experiment — that means “all commits reachable from experiment that aren’t reachable from master.” 
> If, on the other hand, you want to see the opposite — all commits in master that aren’t in experiment — you can reverse the branch names. experiment..master shows you everything in master not reachable from experiment

So in the first case, git log master..experiment shows all commits that
are only on experiment, while git log experiment..master shows all commits
that are only on master.

This above are often confused by most Git users, because they execute the
latter when they want semantics of the former.

I CC'ed Scott Chacon because he wrote the description about revision
range in Pro Git book. Let's see what his opinions are.


An old man doll... just what I always wanted! - Clara

  reply	other threads:[~2021-05-20  5:26 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
2021-05-20  5:26       ` Bagas Sanjaya [this message]
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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \
    --subject='Re: [PATCH] revisions(7): clarify that most commands take a single revision range' \

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