All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	git@vger.kernel.org
Subject: Re: my git problem
Date: Wed, 30 Apr 2008 01:17:50 -0700 (PDT)	[thread overview]
Message-ID: <m3prs7oixp.fsf@localhost.localdomain> (raw)
In-Reply-To: <20080429171519.GA21310@fieldses.org>

"J. Bruce Fields" <bfields@fieldses.org> writes:

> On Mon, Apr 28, 2008 at 12:28:38PM -0700, Linus Torvalds wrote:
>> 
>> 
>> On Mon, 28 Apr 2008, Johannes Schindelin wrote:
>>> 
>>> On Mon, 28 Apr 2008, Andrew Morton wrote:
>>>> 
>>>> That's missing the "logical" bit :)
>>> 
>>> Heh, you're right.  I am too used to Git to think how other people would 
>>> feel about these things... :-)
>> 
>> No, you are both wrong.
>> 
>> You're wrong because apparently you never did abstract algebra and set 
>> theory in school.
[...]
>> If you know math, git actually does the rigth and very much the *logical* 
>> thing.
>> 
>> So ".." is a simple difference, while "..." is a more complex difference. 
>> 
>> They mean different things for different operation types, but that is 
>> again something a math person takes for granted (ie in algebra, a "+" or 
>> "-" is just a random operation that follows certain rules: "a-b" means one 
>> thing for the set of real numbers, and something *totally* different if 
>> you are talking about set algebra).
[...]
> I can sorta buy the argument that "A...B" means most generally "some
> kind of difference between the three sets A, A^B, and B", and that in
> the context of "git diff" it's most sensible to take ordering into
> account and produce some approximation of a diff between A^B and B.  I'd
> personally have found an entirely separate operator simpler to
> understand.  But perhaps there's only so many keys on the keyboard.

IMHO adding support for a..b and a...b to git-diff is a bit of trick,
as a..b and a...b were created to represent a set of revisions (a
revision range).

If we have linear history:

   *---*---*---a---*---*---b

then a..b notation for a revision range is very natural, and having
git-diff interprete "a..b" as "a b" (for git-diff only endpoints
matter) to allow copy'n'pasting between git-log and git-diff, and
between git-fetch messages and git-diff was a good extension.

Now if the history is not linear, as in example below:

   *---*---*---x---*---*---b
                \
                 \-*---a

then "a..b", which is shortcut for "b ^a" (b --not a), returns x..b
range (set) of revisions.  If you read "a..b" as "what's in 'b'
since 'a'" it makes perfect sense.  But "git diff a..b" is still
"git diff a b", not "git diff x b". 


It would be perhaps as good notation to have "git diff a..b" mean
"git diff x b", i.e. be diff between endpoints of "git log a..b",
and have "git diff a...b" be "git diff a b", i.e. to be diff between
endpoints^W points of "git log a...b"... but if there is no clean
winner, simplicity of implementation wins. 

-- 
Jakub Narebski
Poland
ShadeHawk on #git

  reply	other threads:[~2008-04-30  8:18 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-27 18:29 my git problem Andrew Morton
2008-04-27 19:15 ` Linus Torvalds
2008-04-27 19:44   ` Andrew Morton
2008-04-27 20:24     ` Linus Torvalds
2008-04-28 18:45       ` Andrew Morton
2008-04-28 18:49         ` Johannes Schindelin
2008-04-28 19:09           ` Andrew Morton
2008-04-28 19:13             ` Johannes Schindelin
2008-04-28 19:28               ` Linus Torvalds
2008-04-29 17:15                 ` J. Bruce Fields
2008-04-30  8:17                   ` Jakub Narebski [this message]
2008-04-28 19:33               ` Andrew Morton
2008-04-28 19:21         ` Linus Torvalds
2008-04-28 19:54           ` Andrew Morton
2008-05-01  6:01           ` Carl Worth
2008-04-28 19:52         ` Daniel Barkalow
2008-04-28 21:35       ` Andrew Morton
2008-04-28 21:47         ` Linus Torvalds
2008-04-28 22:04           ` Johannes Schindelin
2008-04-28 22:14           ` Linus Torvalds
2008-04-29  2:14             ` Andrew Morton

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=m3prs7oixp.fsf@localhost.localdomain \
    --to=jnareb@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=akpm@linux-foundation.org \
    --cc=bfields@fieldses.org \
    --cc=git@vger.kernel.org \
    --cc=torvalds@linux-foundation.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.