From: David Symonds <hidden> Date: 2016-06-15 22:45:32
Signed-off-by: David Symonds <redacted>
---
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
From: Jeff King <hidden> Date: 2016-06-15 22:45:32
On Tue, Oct 28, 2008 at 04:59:28PM -0700, David Symonds wrote:
quoted hunk
--- /dev/null+++ b/git-staged.sh
@@ -0,0 +1,2 @@+#!/bin/sh+execgitdiff--cached$*
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
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
From: Jeff King <hidden> Date: 2016-06-15 22:45:32
On Wed, Oct 29, 2008 at 02:02:29AM +0100, Johannes Schindelin wrote:
quoted
+git-staged
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?
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
From: Stephan Beyer <hidden> Date: 2016-06-15 22:45:32
Hi,
quoted
--- /dev/null+++ b/git-staged.sh
@@ -0,0 +1,2 @@+#!/bin/sh+execgitdiff--cached$*
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
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. :-)
--
Stephan Beyer [off-list ref], PGP 0x6EDDD207FCC5040F
From: Jeff King <hidden> Date: 2016-06-15 22:45:32
On Wed, Oct 29, 2008 at 02:01:07AM +0100, Stephan Beyer wrote:
I'm still not understanding, what it's for.
Usability? Because doing
git config --global alias.staged 'diff --cached'
is lame?
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
On Wed, Oct 29, 2008 at 02:01:07AM +0100, Stephan Beyer wrote:
quoted
I'm still not understanding, what it's for.
Usability? Because doing
git config --global alias.staged 'diff --cached'
is lame?
You are missing some of the context,
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
What about :
$ git config --global alias.staged "diff --cached"
I'm using this since some time.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:45:32
Hi,
On Wed, 29 Oct 2008, Wincent Colaiuta wrote:
El 29/10/2008, a las 1:44, David Symonds escribió:
quoted
+SCRIPT_SH += git-staged.sh
Isn't this exactly what aliases are for?
git config --global alias.staged "diff --cached"
(Rather than adding yet another command...)
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
From: Jeff King <hidden> Date: 2016-06-15 22:45:32
On Wed, Oct 29, 2008 at 09:33:08AM -0500, Brandon Casey wrote:
quoted
You are missing some of the context,
Yeah, it would have been nice if there was audio.
Anyone take minutes, possibly?
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
From: Stephan Beyer <hidden> Date: 2016-06-15 22:45:32
Hi,
Johannes Schindelin wrote:
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.
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
--
Stephan Beyer [off-list ref], PGP 0x6EDDD207FCC5040F
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:45:32
Hi,
On Wed, 29 Oct 2008, Stephan Beyer wrote:
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.
El 29/10/2008, a las 16:08, Johannes Schindelin escribió:
Hi,
On Wed, 29 Oct 2008, Wincent Colaiuta wrote:
quoted
El 29/10/2008, a las 1:44, David Symonds escribió:
quoted
+SCRIPT_SH += git-staged.sh
Isn't this exactly what aliases are for?
git config --global alias.staged "diff --cached"
(Rather than adding yet another command...)
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.
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
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:45:32
Hi,
On Wed, 29 Oct 2008, Wincent Colaiuta wrote:
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.
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
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.
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.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
El 29/10/2008, a las 18:03, Johannes Schindelin escribió:
Hi,
On Wed, 29 Oct 2008, Wincent Colaiuta wrote:
quoted
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.
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.
The confusion isn't at the command level; it's at the switch/option
level. The solution isn't to add a new command.
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.
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
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:45:32
Hi,
On Wed, 29 Oct 2008, Wincent Colaiuta wrote:
El 29/10/2008, a las 18:03, Johannes Schindelin escribió:
quoted
On Wed, 29 Oct 2008, Wincent Colaiuta wrote:
quoted
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.
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.
The confusion isn't at the command level; it's at the switch/option
level. The solution isn't to add a new command.
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ó:
Hi,
On Wed, 29 Oct 2008, Wincent Colaiuta wrote:
quoted
El 29/10/2008, a las 18:03, Johannes Schindelin escribió:
quoted
On Wed, 29 Oct 2008, Wincent Colaiuta wrote:
quoted
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.
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.
The confusion isn't at the command level; it's at the switch/option
level. The solution isn't to add a new command.
Seems that at leat one guy who does Git training disagrees with you,
_in
addition_ to me.
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
From: Felipe Contreras <hidden> Date: 2016-06-15 22:45:32
On Wed, Oct 29, 2008 at 1:39 AM, David Symonds [off-list ref] wrote:
Signed-off-by: David Symonds <redacted>
---
This isn't a particularly serious patch, but is very relevant to our
current discussion at GitTogether '08.
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.
--
Felipe Contreras