git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Daniel Barkalow <barkalow@iabervon.org>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: Call Me Gitless
Date: Tue, 19 Aug 2008 00:25:06 -0700	[thread overview]
Message-ID: <7vbpzph3fx.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <alpine.LNX.1.00.0808181628420.19665@iabervon.org> (Daniel Barkalow's message of "Mon, 18 Aug 2008 17:31:21 -0400 (EDT)")

Daniel Barkalow <barkalow@iabervon.org> writes:

> .... For most systems, "diff" without options is a preview of 
> what would be in the patch if you were to commit; "git diff", on the other 
> hand, shows what would be left out of the patch.

That is true, but I also think that is because (1) on other systems, you
cannot even choose to select changes to "leave out of the patch", so they
have no option other than showing "what could be committed", and (2) by
definition active use of index means that you are staging incrementally,
and it is natural to expect you to want to view "changes since the last
staging" much more often than "what would be committed" when you are
staging incrementally, so the current default is the _right_ one.

So I'd say the below is a faulty argument:

> ...  So, even given that 
> people understand the meaning of the index, they can fail to understand 
> what "diff" will tell them.

If they understand "the meaning of the index", not just as literal reading
of the manual page "it is a staging area to prepare for the next commit",
but including the reason why there is a "staging area" and how it is to be
used, they would reach the conclusion that "diff by default will show the
leftover from incremental staging and it is the right thing".

> ... And diff is a bit unhelpful in that it 
> generates headers as for "diff -r a b", regardless of what the things are.

We have a separate thread on this now ;-)

>> (2) Some concepts in git are different from what they are used to, without
>>     any good reason.  IOW, the concepts have room for improvement, and our
>>     UI is based on these faulty concepts.
>> 
>> (3) Some concepts in git may be exactly the same with other systems, yet
>>     our UI may operate differently from them without any good reason.
>> 
>> I'd be surprised if there is _no_ UI element that falls into the latter
>> two categories, but obviously I would not be able to list examples.  If I
>> could, they instead would have long been fixed already.
>
> You've got to include the class of "The concepts in git are exactly the 
> same as with other systems (although git also has additional concepts), 
> and commands from other systems do not do the same thing in git (with or 
> without good reason)."

Isn't it the same as (3)?

> E.g., git has a working directory, and git has a committed state, and CVS 
> has both of these, and "cvs diff" compares the working directory with the 
> committed state, but "git diff" does a different operation.

Ah, Ok, that is not the same as (3), but "although git has more" makes it
totally different.

Your example sounds like comparing a car and a motorcycle.  Yes they both
share two tyres, but the former having two more tyres makes the driving
technique of the whole thing quite different, doesn't it?

  parent reply	other threads:[~2008-08-19  7:26 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-18  0:02 Call Me Gitless Trans
2008-08-18  0:28 ` Benjamin Sergeant
2008-08-18  0:40 ` Martin Langhoff
2008-08-18  8:50 ` Pascal Obry
2008-08-18 16:43 ` Jon Loeliger
2008-08-18 19:22 ` Daniel Barkalow
2008-08-18 20:17   ` Marcus Griep
2008-08-18 20:20   ` Junio C Hamano
2008-08-18 21:31     ` Daniel Barkalow
2008-08-18 22:30       ` Junio C Hamano
2008-08-18 23:12         ` Daniel Barkalow
2008-08-19  3:22           ` Junio C Hamano
2008-08-19  3:55             ` Marcus Griep
2008-08-19  6:47               ` Junio C Hamano
2008-08-19  7:02                 ` Junio C Hamano
2008-08-20  8:00                   ` [PATCH v2] diff: vary default prefix depending on what are compared Junio C Hamano
2008-08-20  9:06                     ` Jakub Narebski
2008-08-19  6:28             ` Call Me Gitless Stephen R. van den Berg
2008-08-19 11:42             ` Jakub Narebski
2008-08-19 18:18               ` Junio C Hamano
2008-08-19 17:52             ` Jeff King
2008-08-19 18:39               ` Daniel Barkalow
2008-08-19 18:45                 ` Jeff King
2008-08-19 18:57                   ` Daniel Barkalow
2008-08-19 19:01                     ` Jeff King
2008-08-19 19:42                       ` Daniel Barkalow
2008-08-19 20:33                         ` Petr Baudis
2008-08-19 21:49                           ` Daniel Barkalow
2008-08-19 19:43               ` Junio C Hamano
2008-08-19  7:25       ` Junio C Hamano [this message]
2008-08-19 19:22         ` Daniel Barkalow
2008-08-21  3:40       ` Sverre Hvammen Johansen
2008-08-21  8:41       ` Junio C Hamano
2008-08-21  8:43         ` [PATCH 1/3] sha1_object_info(): pay attention to cached objects Junio C Hamano
2008-08-21  8:43         ` [PATCH 2/3] cached_object: learn empty blob Junio C Hamano
2008-08-21  8:44         ` [PATCH 3/3] git-add --intent-to-add (-N) Junio C Hamano
2008-08-21 14:23           ` Paolo Bonzini
2008-08-21 21:14           ` Jonathan Nieder
2008-08-22  4:10             ` Jonathan Nieder
2008-08-22  4:34               ` Daniel Barkalow
2008-08-22  4:59                 ` Junio C Hamano
2008-08-22  5:32                 ` Jonathan Nieder
2008-08-22  5:59                   ` Junio C Hamano
2008-08-22  6:38                     ` Jonathan Nieder
2008-08-22  7:52                       ` Jonathan Nieder
2008-08-21 13:58         ` Call Me Gitless Daniel Barkalow
2008-08-18 23:24     ` Tarmigan
2008-08-19  0:32       ` Daniel Barkalow
2008-08-19  0:45         ` Tarmigan
2008-08-19  7:53       ` "Peter Valdemar Mørch (Lists)"
2008-08-19  8:01         ` Junio C Hamano
2008-08-19  8:10           ` Imran M Yousuf
2008-08-19  8:26             ` "Peter Valdemar Mørch (Lists)"
2008-08-19  8:53               ` Imran M Yousuf
2008-08-19  8:57           ` Alexander E Genaud
2008-08-19  9:11             ` Matthieu Moy
2008-08-19  9:36               ` Mike Hommey
2008-08-19 10:09               ` Alexander E Genaud
2008-08-19 11:27                 ` Pascal Obry
2008-08-21 14:15                   ` Paolo Bonzini
2008-08-22 19:10                     ` Elijah Newren
2008-08-19 10:16               ` "Peter Valdemar Mørch (Lists)"
2008-08-19 11:31             ` Mark Struberg
2008-08-19 12:04               ` Alexander E Genaud
2008-08-19 18:15                 ` Junio C Hamano
2008-08-19  8:56         ` Teemu Likonen
2008-08-19 13:15 ` Jakub Narebski

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=7vbpzph3fx.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=barkalow@iabervon.org \
    --cc=git@vger.kernel.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).