Re: [RFC/PATCH 0/2] New 'stage' command

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Apr 7, 2009, 12:45 UTC
Message-ID: <alpine.DEB.1.00.0904071443530.6897@intel-tinevez-2-302>
In-Reply-To: <94a0d4530904070301k62687e2i772637068494ab74@mail.gmail.com>

Hi,

On Tue, 7 Apr 2009, Felipe Contreras wrote:

Show 26 quoted lines

> On Mon, Apr 6, 2009 at 10:25 PM, Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
> > On 2009.04.06 22:13:26 +0300, Felipe Contreras wrote:
> >> On Mon, Apr 6, 2009 at 9:30 PM, Junio C Hamano <gitster@pobox.com> wrote:
> >> > David Kågedal <davidk@lysator.liu.se> writes:
> >> >
> >> >> What do you mean? This was a suggestion for how git diff should
> >> >> work. I fail to see how you would need a WORKTREEANDTHEINDEX there.
> >> >
> >> > You are talking only about "git diff".  I am talking about the whole git
> >> > suite, because you have to worry about how such a proposal would affect
> >> > other parts of the UI.
> >>
> >> How do currently do you something like this:
> >> git diff HEAD^..STAGE
> >
> > git diff --cached HEAD^
> >
> > The "hard" (and pretty weird) one would be "git diff STAGE..HEAD^",
> > which is:
> >
> > git diff -R --cached HEAD^
> 
> Sorry, that's what I meant.
> 
> So it's possible, but completely unintuitive, and different from other
> use cases.

At least it is consistent.

You are always able to say "-R" if you want to have the reverse diff, this is commonly known from GNU diff and other diff implementations.

Also, "git diff --cached" is _only_ a shortcut for "git diff --cached HEAD". This is yet another proof that you should not teach the shortcuts first, it _harms_ understanding.

Ciao, Dscho