git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Francis Moreau" <francis.moro@gmail.com>
To: "Junio C Hamano" <junkio@cox.net>
Cc: "Jay Cliburn" <jacliburn@bellsouth.net>,
	git@vger.kernel.org, "Jeff Garzik" <jeff@garzik.org>,
	"Linus Torvalds" <torvalds@osdl.org>
Subject: Re: Updated Kernel Hacker's guide to git
Date: Fri, 22 Dec 2006 21:34:50 +0100	[thread overview]
Message-ID: <38b2ab8a0612221234x3832c5bfr1f64caccbb8247b9@mail.gmail.com> (raw)
In-Reply-To: <7vvek41b29.fsf@assigned-by-dhcp.cox.net>

On 12/22/06, Junio C Hamano <junkio@cox.net> wrote:
> "Francis Moreau" <francis.moro@gmail.com> writes:
>
> > I think this part is really confusing. For a new comer, saying that:
> >
> >       git diff a b == git diff a..b
> >
> > is really not intuitive. Maybe just because adding a new symbol ".."
> > in git diff command line means (for me) that we're doing a special
> > diff. I would never thought by my own that ".." means a simple "to".
>
> We did not originally have "A B"; you were supposed to always
> say "A..B".  But all other SCM had "A B" notation, so we added
> support for both because doing so was trivial and there is no
> risk of confusion (because diff is about two points while log is
> about a set).  These two notations are interchangeable for
> "diff".  If it confuses you, you can stick to the "git diff A B"
> notation.  Of if you are like Linus, stick to "A..B" notation.
> Either way, you can pretend that the other notation does not
> even exist and be happy ;-).
>

no, no, I think you miss my point here. What is confusing, and it
seems I'm not the only one to find it confusing,  is the fact that
"git diff A B == git diff A..B", not the "A..B" notation per se.

git diff A B, is really intuitive and easy to understand because we
all use to using the diff "A B" notation and it always has worked with
2 endpoints. So I would bet that all newbies who use for the first
time the git diff command will use "A B" notation, not "A..B" one.

> Yes, users often wondered why "git diff" accepts "A B", "git
> log" wants "A..B" and "git log A B" is a disaster.  But the root
> cause of the confusion was not about notation but about the
> conceptual difference (two points vs a set).
>
> I do not think changing the meaning of "diff A..B" to what "diff
> A...B" means is a good thing.  The notation "..." even _looks_
> like a magic, and in diff context, what it does _is_ magic (it
> is magic in log context, too).  You are giving two points, but

But ".." is magic too ! I would really expect something magic to
happen when using the "A..B" notation because I'm a new comer in git
and I never used the "A..B" notation before.

And since I already used this notation when using git log command, I
would expect "git diff A..B" to give the current result given by "git
diff A...B".

But yes, now I have understand that git diff works with end points
unlike git log, I can stick with two notations:

        git diff A B
        git diff A...B (3 dots)

and I'm happy ;)

thanks
-- 
Francis

  reply	other threads:[~2006-12-22 20:35 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-21 12:24 Updated Kernel Hacker's guide to git Francis Moreau
2006-12-21 18:23 ` Linus Torvalds
2006-12-22  1:23   ` Carl Worth
2006-12-22  4:13     ` Linus Torvalds
2006-12-22 22:20       ` Carl Worth
2006-12-22 22:34         ` Linus Torvalds
2006-12-22 22:45         ` Junio C Hamano
2006-12-22 23:31           ` Carl Worth
2006-12-22 23:00         ` Jakub Narebski
2006-12-22  9:35   ` Francis Moreau
2006-12-22 10:26     ` Junio C Hamano
2006-12-22 20:34       ` Francis Moreau [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-12-21  3:04 Jeff Garzik
2006-12-21  3:21 ` Jay Cliburn
2006-12-21  7:04   ` Martin Langhoff
2006-12-21  7:32     ` Junio C Hamano
2006-12-21  7:51   ` Linus Torvalds
2006-12-21 11:53   ` Jeff Garzik
2006-12-21  5:44 ` Willy Tarreau
2006-12-21  5:53 ` Nigel Cunningham
2006-12-21 11:44   ` Jeff Garzik
2006-12-21 21:17     ` Nigel Cunningham
2006-12-21 13:53 ` Francois Romieu
2006-12-21 20:40 ` Guennadi Liakhovetski
2006-12-21 20:46   ` Jeff Garzik
2006-12-22  8:50 ` Jesper Juhl
2006-12-24 18:07 ` Horst H. von Brand
2007-12-23 11:13   ` Jeff Garzik
2007-12-23 12:08     ` Robert P. J. Day
2007-12-23 12:13       ` Jeff Garzik
2007-12-23 12:20         ` Robert P. J. Day
2007-12-23 13:05           ` Dieter Ries
2007-12-23 17:23             ` Robert P. J. Day
2007-12-23 20:14             ` Stefan Richter
2007-12-24 14:19             ` Robert P. J. Day
2007-12-23 12:25     ` WANG Cong
2007-12-24 12:50     ` Miklos Vajna
2007-12-25 13:08     ` Salikh Zakirov
2007-12-31  2:50     ` Jan Engelhardt
2007-12-31 11:26       ` Stefan Richter
2007-12-31 17:31         ` Junio C Hamano
2008-06-30  2:51         ` Jeff Garzik
2008-06-30  6:27           ` Stefan Richter
2008-06-30  2:49       ` Jeff Garzik
2008-07-03  6:26         ` Christian Couder

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=38b2ab8a0612221234x3832c5bfr1f64caccbb8247b9@mail.gmail.com \
    --to=francis.moro@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jacliburn@bellsouth.net \
    --cc=jeff@garzik.org \
    --cc=junkio@cox.net \
    --cc=torvalds@osdl.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 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).