Re: Start deprecating "git-command" in favor of "git command"

Linus Torvalds [off-list ref] writes:

Using "git xyzzy" also has some fundamental advantages, like the ability 
to specify things like paging ("git -p xyzzy") and making the whole notion 
of aliases act like other git commands (which they already do, but they do 
*not* have a "git-xyzzy" form!)

In the longer run, we may want to allow "git foo" to alias to
"git foo --preferred-options", although we currently do not
allow such an alias.  Scripts, especially the ones we ship,
would not want to be confused by the user aliases when that
happens.

Anyway, while actually removing the "git-xyzzy" things is not practical 
right now, we can certainly start slowly to deprecate it internally inside 
git itself - in the shell scripts we use, and the test vectors.

So I am somewhat negative on this, unless there is a way for
scripts to say "Even though I say 'git foo', I do mean 'git foo'
not whatever the user has aliased".

On Sat, Jun 30, 2007 at 12:17:10PM -0700, Junio C Hamano wrote:

So I am somewhat negative on this, unless there is a way for
scripts to say "Even though I say 'git foo', I do mean 'git foo'
not whatever the user has aliased".

"git --no-alias foo" (like "cvs -f foo" which ignores ~/.cvsrc) ?

Best regards,
-- 
Yann

On Sat, 30 Jun 2007, Junio C Hamano wrote:

In the longer run, we may want to allow "git foo" to alias to
"git foo --preferred-options", although we currently do not
allow such an alias.  Scripts, especially the ones we ship,
would not want to be confused by the user aliases when that
happens.

I agree. And I think our current behaviour is the correct one.

So I am somewhat negative on this, unless there is a way for
scripts to say "Even though I say 'git foo', I do mean 'git foo'
not whatever the user has aliased".

Well, we have a more serious issue, that is related, but has nothing to do 
with aliases.

If you set an environment variable "diff.color=always", any script will 
get that behaviour, and not work the way it might expect.

My point being that this has nothing to do with "git-diff" vs "git diff", 
and everything to do with default configurations. If you don't want people 
to be able to change fixed behaviour, you'd need to have a way to disable 
it.

Quite frankly, I think it's _easier_ to disable with "git xyzzy" than with 
"git-xyzzy", but hey, not a big deal. With "git xyzzy", we could add a 
generic flag like

	git - xyzzy

to make the rule be that no configurations (_including_ aliases) are 
allowed to override default behaviour, which is much harder with the 
"git-xyzzy" format (since then it's invariably a per-command thing).

That said, I'm not going to push that patch very hard.

Especially as I just realized that it had a bug: it caused things like

	-our \$logo = "file:///$(pwd)/../../gitweb/git-logo.png";
	+our \$logo = "file:///$(pwd)/../../gitweb/git logo.png";

because "git-log" got rewritten as "git log", without checking that it was 
a proper word.

I have a fixed version already (just make the sed script use \<..\> around 
the pattern - appended here), but as mentioned, I don't think this is a 
hugely important issue. I prefer the "git cmd" form, but if we want to 
maintain "git-cmd" forever, then hey...

		Linus
---

Fixed the sed pattern a bit..

 Makefile             |    3 ++-
 fixup-builtins       |   16 ++++++++++++++++
 git-filter-branch.sh |    2 +-
 3 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index a98e27a..1620ef8 100644
--- a/Makefile
+++ b/Makefile

@@ -987,7 +987,8 @@ check-sha1:: test-sha1$X
 check: common-cmds.h
 	for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i || exit; done
 
-
+remove-dashes:
+	./fixup-builtins $(BUILT_INS)
 
 ### Installation rules
 

diff --git a/fixup-builtins b/fixup-builtins
new file mode 100755
index 0000000..49e861d
--- /dev/null
+++ b/fixup-builtins

@@ -0,0 +1,16 @@
+#!/bin/sh
+while [ "$1" ]
+do
+	old="$1"
+	new=$(echo "$1" | sed 's/git-/git /')
+	echo "Converting '$old' to '$new'"
+	git ls-files '*.sh' | while read file
+	do
+		sed "s/\\<$old\\>/$new/g" < $file > $file.new
+		chmod --reference=$file $file.new
+		mv $file.new $file
+	done
+	shift
+done
+git update-index --refresh >& /dev/null
+exit 0

diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 8fa5ce6..0f54271 100644
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh

@@ -383,7 +383,7 @@ while read commit parents; do
 
 	sed -e '1,/^$/d' <../commit | \
 		eval "$filter_msg" | \
-		sh -c "$filter_commit" git-commit-tree $(git-write-tree) $parentstr | \
+		sh -c "$filter_commit" "git-commit-tree" $(git-write-tree) $parentstr | \
 		tee ../map/$commit
 done <../revs
 

On Sat, Jun 30, 2007 at 12:17:10PM -0700, Junio C Hamano wrote:

So I am somewhat negative on this, unless there is a way for
scripts to say "Even though I say 'git foo', I do mean 'git foo'
not whatever the user has aliased".

I had submitted GIT_NOALIAS=1 patches a while back, but IIRC, the
consensus was that it was a bit too ugly and fragile in concept.

-Peff

Hi,

On Sun, 1 Jul 2007, Jeff King wrote:

On Sat, Jun 30, 2007 at 12:17:10PM -0700, Junio C Hamano wrote:

quoted

So I am somewhat negative on this, unless there is a way for
scripts to say "Even though I say 'git foo', I do mean 'git foo'
not whatever the user has aliased".

I had submitted GIT_NOALIAS=1 patches a while back, but IIRC, the
consensus was that it was a bit too ugly and fragile in concept.

I think it is not GIT_NOALIAS that is ugly and fragile in concept. It is 
the whole notion that you can define default parameters via aliases that 
is ugly and fragile.

The possibility to say

	git config alias.log '!rm -rf /home/peff'

on somebody _else's_ machine makes me go shudder.

And there's another thing. On some machines, rm is aliased to 'rm -i'. 
That's good, right? NO! It _forces_ me to either look at the aliases on 
that particular box, or alternatively (which is what I actually do), 
specify _exactly_ what I want (I never do "rm", I always do "rm -i" or "rm 
-f", or "git rm"). That's because the default behaviour is 
_different_ on _different_ boxes. Repeat after me: consistency is good, 
inconsistency is bad.

So, yes, I am glad we have the option of using GIT_NOALIAS (which I forgot 
until jasam had this idea on IRC, independently), but no, I'd like not to 
use it. Not because GIT_NOALIAS is ugly, but because individual 
overriding default behaviours via peculiar aliases is.

Ciao,
Dscho

Johannes Schindelin wrote:

Hi,

On Sun, 1 Jul 2007, Jeff King wrote:

quoted

On Sat, Jun 30, 2007 at 12:17:10PM -0700, Junio C Hamano wrote:

quoted

So I am somewhat negative on this, unless there is a way for
scripts to say "Even though I say 'git foo', I do mean 'git foo'
not whatever the user has aliased".

I had submitted GIT_NOALIAS=1 patches a while back, but IIRC, the
consensus was that it was a bit too ugly and fragile in concept.

I think it is not GIT_NOALIAS that is ugly and fragile in concept. It is 
the whole notion that you can define default parameters via aliases that 
is ugly and fragile.

The possibility to say

	git config alias.log '!rm -rf /home/peff'

on somebody _else's_ machine makes me go shudder.

And there's another thing. On some machines, rm is aliased to 'rm -i'. 
That's good, right? NO! It _forces_ me to either look at the aliases on 
that particular box, or alternatively (which is what I actually do), 
specify _exactly_ what I want (I never do "rm", I always do "rm -i" or "rm 
-f", or "git rm"). That's because the default behaviour is 
_different_ on _different_ boxes. Repeat after me: consistency is good, 
inconsistency is bad.

And to give a git-specific example, I suspect many people would see this
feature and immediately do "git config alias.commit "commit -a".

- Josh Triplett