patchImplement git-staged, an alias for 'git diff --cached'.

Signed-off-by: David Symonds <dsymonds@gmail.com>
---
  This isn't a particularly serious patch, but is very relevant to our
  current discussion at GitTogether '08.

 .gitignore    |    1 +
 Makefile      |    1 +
 git-staged.sh |    8 ++++++++
 3 files changed, 10 insertions(+), 0 deletions(-)
 create mode 100755 git-staged.sh

On Tue, Oct 28, 2008 at 04:39:05PM -0700, David Symonds wrote:

Do you even need to do sh-setup? How about

  #!/bin/sh
  exec git diff --cached "$@"

-Peff

Signed-off-by: David Symonds <dsymonds@gmail.com>
---
 .gitignore    |    1 +
 Makefile      |    1 +
 git-staged.sh |    2 ++
 3 files changed, 4 insertions(+), 0 deletions(-)
 create mode 100755 git-staged.sh

On Tue, Oct 28, 2008 at 04:59:28PM -0700, David Symonds wrote:

This is broken for arguments with spaces. Use "$@" instead.

But I think this isn't a serious patch anyway, so we are probably wasting too much time on it. ;P

-Peff

Signed-off-by: David Symonds <dsymonds@gmail.com>
---
 .gitignore    |    1 +
 Makefile      |    1 +
 git-staged.sh |    2 ++
 3 files changed, 4 insertions(+), 0 deletions(-)
 create mode 100755 git-staged.sh

Hi,

On Tue, 28 Oct 2008, David Symonds wrote:

Would it not be better to teach "git show --staged" to do that, and to add a command pair "git stage <file>" and "git unstage <file>" to do the obvious?

Ciao, Dscho

On Wed, Oct 29, 2008 at 02:02:29AM +0100, Johannes Schindelin wrote:

Yes, I think half of the discussion went on IRC. But I don't think "git staged" is a good idea. I think a "--staged" alias for "--cached" in "git diff" makes a lot more sense.

-Peff

El 29/10/2008, a las 1:44, David Symonds escribió:

Isn't this exactly what aliases are for?
   git config --global alias.staged "diff --cached"
(Rather than adding yet another command...)

Wincent

Hi,

On Wed, 29 Oct 2008, Wincent Colaiuta wrote:

The difference being, of course, that we do not ship default aliases (and neither do we plan to...).

So saying "this is what aliases are for" you ask for _newbies_ to add it for themselves. We are talking the same newbies who should be helped by that command, and typically do not know that there are Git aliases yet.

Even worse, just sum the times it takes everybody to make that alias, and then compare with the time it would take to include something like David posted in git.git. It should be obvious that the time balance is absolutely horrible.

Ciao, Dscho

Hi,

Johannes Schindelin wrote:

I'm not sure if yet more commands really help newbies.

I *see* the problem that talking about the index, the cache and the staging area can be difficult to newbies. But then I'd rather vote for "git diff --staged" (instead of --cached) or "git show --staged" (both make sense in some way). Perhaps it is even sufficient to add a help text to "git status", like this:

 # Changes to be committed:
 #   (use "git reset HEAD <file>..." to unstage)
+#   (use "git diff --cached" to see a diff of staged files)

For me, a "git staged" feels wrong without a "git stage" (alias for "git add") and "git unstage <file>" (alias for "git reset <file>"). And I think the list of examples can easily be continued.

Regards,
  Stephan

Hi,

On Wed, 29 Oct 2008, Stephan Beyer wrote:

http://article.gmane.org/gmane.comp.version-control.git/99340

Thanks, Dscho

El 29/10/2008, a las 16:08, Johannes Schindelin escribió:

Git already has too many commands. Adding more is not going to clear up newbie confusion, and will only waste time because people will complain about it and ask why there is this kind of duplication.

W

Hi,

On Wed, 29 Oct 2008, Wincent Colaiuta wrote:

I completely disagree. If the existing set of commands causes confusion, we need to deprecate those parts and add new commands. Even if we have a ton of commands already.

It does not need to hurt, either. Just think of init-db. Ever heard of it? We still have it, yet it is not relevant.

Ciao, Dscho

Johannes Schindelin a écrit :

In this specific case adding a new command as an alias for a command+option seems wrong! I much prefer adding the alias --staged for --cached - as proposed now - if it can make things easier for new comers.

Pascal.

El 29/10/2008, a las 18:03, Johannes Schindelin escribió:

The confusion isn't at the command level; it's at the switch/option level. The solution isn't to add a new command.

The comparison isn't really valid. init-db is effectively invisible, but you're talking about adding a new "in your face" porcelain command.

W

Wincent Colaiuta (2008-10-29 18:42 +0100) wrote:

I don't remember being confused in particular area but I think it's a _very_ good thing that the following three are behind the same "diff" command:

    git diff
    git diff --cached       (or --staged)
    git diff HEAD

It's also good idea to pretty much always teach those three together.

Teemu Likonen <tlikonen@iki.fi> writes:

One irregularity hear is that there is no way to explicitly say what you want to compare against the index (the staging area). Diff compares two things to each other, and a more regular and general way to express what it does would be something like

    git diff STAGE WORKTREE   (like "git diff" today)
    git diff HEAD WORKTREE    (like "git diff HEAD" today)
    git diff WORKTREE HEAD    (like "git diff -R HEAD" today)
    git diff HEAD STAGE       (like "git diff --cached" today)
    git diff commit STAGE     (like "git diff --cached commit" today)

To me, it isn't obvious that --cached changes the thing you *compare* rather than the thing you compare *against*. I think it would be useful to have a way of explicitly stating what you compare, something like what I wrote above, and then having useful shortcuts for common cases (like that no arguments compares the work tree against the stage).

Hi,

On Wed, 29 Oct 2008, Wincent Colaiuta wrote:

Seems that at leat one guy who does Git training disagrees with you, _in addition_ to me.

Ciao, Dscho

El 29/10/2008, a las 20:23, Johannes Schindelin escribió:

That's what I call a "zero value" addition to the thread, seeing as anyone reading the thread _already_ knows the opinions of the participants who've posted.

Adding a separate command to an already overwhelming command set in order to address confusion about options to "git diff" is a case of "duct-tape UI design".

Wincent

Hi,

I'm still not understanding, what it's for.
Usability? Because doing
	git config --global alias.staged 'diff --cached'
is lame?

Regards,
  Stephan

PS: Btw, if ever meant serious, it's missing an insertion into
    command-list.txt and serious documentation.
    But I think you know that. :-)

On Wed, Oct 29, 2008 at 02:01:07AM +0100, Stephan Beyer wrote:

You are missing some of the context, which is that we just had a big in-person debate about how the staged nomenclature is confusing. We call things "cached", "staged", and "index", depending on the command.

So this is an attempt to rectify that.

-Peff

Jeff King wrote:

Yeah, it would have been nice if there was audio. Anyone take minutes, possibly?

btw the term "staged" makes perfect sense to me, whereas "cached" was not intuitively obvious to me.

-brandon

On Wed, Oct 29, 2008 at 09:33:08AM -0500, Brandon Casey wrote:

There's no audio. Some of the slides will be available. I took notes on at least one of the discussions, which I will try to summarize and post. And I think some of the discussion will end up as patches, which will hopefully provide full justification in their commit messages. ;)

-Peff

What about :

   $ git config --global alias.staged "diff --cached"

I'm using this since some time.

On Wed, Oct 29, 2008 at 1:39 AM, David Symonds <dsymonds@gmail.com> wrote:

I've thought about some commands like: git stage $file (git add $file) git unstage $file (git reset $file)

Perhaps git stage add git stage rm

And then your proposal would fit with: git stage diff

Or something like that.