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

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

[Linus Torvalds]

I realize that a lot of people use the "git-xyzzy" format, and we have 
various historical reasons for it, but I also think that most people have 
long since started thinking of the git command as a single command with 
various subcommands, and we've long had the documentation talk about it 
that way.

Slowly migrating away from the git-xyzzy format would allow us to 
eventually no longer install hundreds of binaries (even if most of them 
are symlinks or hardlinks) in users $PATH, and the _original_ reasons for 
it (implementation issues and bash completion) are really long long gone.

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!)

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.

This patch adds a "remove-dashes" makefile target, which does that. It 
isn't particularly efficient or smart, but it *does* successfully rewrite 
a lot of our shell scripts to use the "git xyzzy" form for all built-in 
commands.

(For non-builtins, the "git xyzzy" format implies an extra execve(), so 
this script leaves those alone).

So apply this patch, and then run

	make remove-dashes
	make test
	git commit -a

to generate a much larger patch that actually starts this transformation.

(The only half-way subtle thing about this is that it also fixes up 
git-filter-branch.sh for the new world order by adding quoting around 
the use of "git-commit-tree" as an argument. It doesn't need it in that 
format, but when changed into "git commit-tree" it is no longer a single 
word, and the quoting maintains the old behaviour).

NOTE! This does not yet mean that you can actually stop installing the 
"git-xyzzy" binaries for the builtins. There are some remaining places 
that want to use the old form, this just removes the most obvious ones 
that can easily be done automatically.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---

Comments? I think this is worth doing, but the patch that this scripting 
generates is actually fairly large, even if this patch itself is smallish.

Junio, up to you.

 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..d7fae43
--- /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
 

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

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> 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".

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

[Yann Dirson]

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

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

[Linus Torvalds]

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
 

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

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> 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.

That's exactly why we have told people to use plumbing in their
scripts, and git-diff-tree does not look at diff.color.

> 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).

But that would break existing scripts wouldn't it?

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

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> 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".

Having said that, I am not opposed to encourage distros to set
gitexecdir to $(prefix)/libexec in their modified Makefile.
There is no reason to contaminate a directory on end users'
$PATH with hundreds of commands that begin with "git-" prefix.

In fact, I used to configure my copy of git with gitexecdir set
to outside my $PATH when we first started pushing it to make
sure everything works (I do not install git from distro on my
machine so I know I have only one instance of bin/git in my
path).  It used to work, but I am no longer using that layout
these days, so it is entirely possible that we might have broken
the support along the way.  And _that_ is worth fixing.

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

[walt]

Linus Torvalds wrote:
> I realize that a lot of people use the "git-xyzzy" format, and we have 
> various historical reasons for it...

One of the historical reasons was to allow users of gnu interactive
tools to delete the git wrapper script, as outlined in 'INSTALL'.

Seems unlikely that 'git' could still be deleted if your proposed
changes are implemented.  I recall that a few people cared a lot
about this, and not too long ago.

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

[Johannes Schindelin]

Hi,

On Sat, 30 Jun 2007, walt wrote:

> Linus Torvalds wrote:
> > I realize that a lot of people use the "git-xyzzy" format, and we have
> > various historical reasons for it...
> 
> One of the historical reasons was to allow users of gnu interactive
> tools to delete the git wrapper script, as outlined in 'INSTALL'.
> 
> Seems unlikely that 'git' could still be deleted if your proposed
> changes are implemented.  I recall that a few people cared a lot
> about this, and not too long ago.

All this would be less of a problem if Git consisted only of builtins, 
since you could easily do "mv git gitscm" then. *sigh*

Ciao,
Dscho

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

[walt]

Johannes Schindelin wrote:
> Hi,
> 
> On Sat, 30 Jun 2007, walt wrote:
> 
>> Linus Torvalds wrote:
>>> I realize that a lot of people use the "git-xyzzy" format, and we have
>>> various historical reasons for it...
>> One of the historical reasons was to allow users of gnu interactive
>> tools to delete the git wrapper script, as outlined in 'INSTALL'.
...
> All this would be less of a problem if Git consisted only of builtins, 
> since you could easily do "mv git gitscm" then. *sigh*

I just installed the gnu tools as a test (gentoo won't allow both gits to
be installed at the same time, btw) and I found that each package installs
one main 'git' along with a collection of other tools beginning with the
prefix git.

One major difference is that our git names them git-* while the gnu tools
names them git*, so only the main 'git's conflict.  The gnu 'git' can also
be renamed and it still works.  'man git' might still be a problem.

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

[linux]

H'm... I use the git-foo forms a lot so I can do easy history substitution.
In particular, "!git-grep" (actually, "!git-g") gets used a fair bit.

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

[eschvoca]

By removing the dash I would miss out on man pages too.  I don' t like
seeing all the rare commands pollute my PATH.

In zsh while I'm typing a command like:

$ git-rebase branch --

I then realize I need the man page so I type "Esc-h" and it appears.
When I exit man I'm back to the same spot in the command line.

e

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

[Junio C Hamano]

Yann Dirson <ydirson@altern.org> writes:

> 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) ?

The current scripts that largely use "git-foo" do not have to be
changed.  Your --no-alias and Linus's "git - foo" would be a
"solution", but both require changes to the scripts -- and that
"solution" is necessary only because we would rewrite calls to
"git-foo" in existing scripts to "git foo" today?

No, thanks.  We should do better than that.

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

[Theodore Tso]

On Sat, Jun 30, 2007 at 09:48:26PM -0400, eschvoca wrote:
> By removing the dash I would miss out on man pages too.

The man pages are something that needs careful consideration.  Some
man programs use the PATH as a hint to figure out which man page to
show --- i.e., if /usr/local/bin/git-log is in the path then it's
likely that the man page you want to show is the one in
/usr/local/man/man1/git-log.1.

If we don't install git-log in the PATH, for some setups people won't
be able to see the man page for git-log.

						- Ted

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

[Linus Torvalds]

On Sat, 30 Jun 2007, Junio C Hamano wrote:
> 
> The current scripts that largely use "git-foo" do not have to be
> changed.  Your --no-alias and Linus's "git - foo" would be a
> "solution", but both require changes to the scripts

No. I didn't (and wouldn't) _remove_ the "git-xyzzy" thing.

I'm just saying that it should be considered a secondary thing, and we 
should have the long-term *option* to remove it.

And in order to do that, we should start removing our dependency on it 
earlier rather than later.

Your whole alias argument is bogus, since we don't _allow_ aliases to 
override the command (as you yourself did admit).

So changing the current scripts from using "git-xyzzy" to using "git 
xyzzy" changes nothing at all - except it gives people the _option_ to 
stop installing the git-* links if they don't want to.

With my script, you can actually do it and have a mostly working setup. 
Yeah, not installing the git-* links will actually break some things, but 
it won't break the really common stuff. 

As it is, we have to have the git-* links somewhere, and I don't see why 
you or others argue that that _requirement_ is somehow a better thing than 
not requiring it.

With my patch, it's a _choice_, rather than a straight-jacket.

		Linus

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

[Junio C Hamano]

Linus Torvalds <torvalds@linux-foundation.org> writes:

> On Sat, 30 Jun 2007, Junio C Hamano wrote:
>> 
>> The current scripts that largely use "git-foo" do not have to be
>> changed.  Your --no-alias and Linus's "git - foo" would be a
>> "solution", but both require changes to the scripts
>
> No. I didn't (and wouldn't) _remove_ the "git-xyzzy" thing.
>
> I'm just saying that it should be considered a secondary thing, and we 
> should have the long-term *option* to remove it.
>
> And in order to do that, we should start removing our dependency on it 
> earlier rather than later.
>
> Your whole alias argument is bogus, since we don't _allow_ aliases to 
> override the command (as you yourself did admit).
>
> So changing the current scripts from using "git-xyzzy" to using "git 
> xyzzy" changes nothing at all - except it gives people the _option_ to 
> stop installing the git-* links if they don't want to.

People who do not want to have git-xyzzy in their PATH had that
choice for eternity ("make gitexecdir=$(prefix)/libexec/git");
your patch is not needed to satisfy that.

What it buys us is that they do not have to have
$(prefix)/libexec/git/git-xyzzy for all xyzzy that git.c knows
about as built-ins (obviously non built-ins are still needed).
I do see value in not cluttering $(prefix)/bin/ quite a lot, but
does it matter if we have 140 links or 70 links (the differences
are 70 or so built-ins we currently have) in $(prefix)/libexec/git?

I would not be objecting to it if this was about $(bindir).

> With my patch, it's a _choice_, rather than a straight-jacket.

But that is a different choice.  Choice of having only 70
git-xyzzy in $(gitexecdir) vs having to have 140 (among which 70
are hardlinks).

Your patch _closes the door_ for us to implement overriding
aliases later if we wanted to; we would need to go back to the
scripts and say "git --no-alias xyzzy" again.

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

[Jeff King]

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

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

[Johannes Schindelin]

Hi,

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

> Your patch _closes the door_ for us to implement overriding aliases 
> later if we wanted to; we would need to go back to the scripts and say 
> "git --no-alias xyzzy" again.

No, it does not.

Carlos had a cute idea on IRC, but was too shy to mention it here. There 
is a central place for Git's shell script, git-sh-setup. Defining an 
environment variable there, GIT_NO_ALIAS, and honouring that in the Git 
wrapper. Something similar is possible in Git.pm for perl scripts.

Note: I am opposed to overriding default parameters via alias. I am only 
stating that it is still possible.

I am in favour of Linus' patch. Here's why: quite some times, I have been 
asked (at a very late stage) "What still confuses me: what is the 
difference between git-xyz and git xyz?" It _is_ confusing for beginners, 
even if it is easy to explain.

Ciao,
Dscho

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

[Yann Dirson]

On Sat, Jun 30, 2007 at 10:37:07PM +0100, Johannes Schindelin wrote:
> Hi,
> 
> On Sat, 30 Jun 2007, walt wrote:
> 
> > Linus Torvalds wrote:
> > > I realize that a lot of people use the "git-xyzzy" format, and we have
> > > various historical reasons for it...
> > 
> > One of the historical reasons was to allow users of gnu interactive
> > tools to delete the git wrapper script, as outlined in 'INSTALL'.
> > 
> > Seems unlikely that 'git' could still be deleted if your proposed
> > changes are implemented.  I recall that a few people cared a lot
> > about this, and not too long ago.
> 
> All this would be less of a problem if Git consisted only of builtins, 
> since you could easily do "mv git gitscm" then. *sigh*

That *would* be a problem for all porcelains - stgit, guilt, qgit,
etc, all have to find git...

Best regards,
-- 
Yann

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

[Johannes Schindelin]

Hi,

On Sun, 1 Jul 2007, Jeff King wrote:

> 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.

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

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

[Junio C Hamano]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Carlos had a cute idea on IRC, but was too shy to mention it here. There 
> is a central place for Git's shell script, git-sh-setup. Defining an 
> environment variable there, GIT_NO_ALIAS, and honouring that in the Git 
> wrapper. Something similar is possible in Git.pm for perl scripts.
>
> Note: I am opposed to overriding default parameters via alias. I am only 
> stating that it is still possible.
>
> I am in favour of Linus' patch. Here's why: quite some times, I have been 
> asked (at a very late stage) "What still confuses me: what is the 
> difference between git-xyz and git xyz?" It _is_ confusing for beginners, 
> even if it is easy to explain.

Ok, please consider the idea sold.

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

[Josh Triplett]

Johannes Schindelin wrote:
> Hi,
> 
> On Sun, 1 Jul 2007, Jeff King wrote:
> 
>> 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.
> 
> 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

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

[Nicolas Pitre]

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

> Your patch _closes the door_ for us to implement overriding
> aliases later if we wanted to; we would need to go back to the
> scripts and say "git --no-alias xyzzy" again.

I think such aliases would be evil.  Closing the door on them is most 
certainly a good thing IMHO.


Nicolas

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

[Junio C Hamano]

Nicolas Pitre <nico@cam.org> writes:

> On Sat, 30 Jun 2007, Junio C Hamano wrote:
>
>> Your patch _closes the door_ for us to implement overriding
>> aliases later if we wanted to; we would need to go back to the
>> scripts and say "git --no-alias xyzzy" again.
>
> I think such aliases would be evil.  Closing the door on them is most 
> certainly a good thing IMHO.

Ok.

Now my 'next' is coming very close to 'master' while preparing
for 1.5.3-rc0, it may be a good time to apply Linus's magic.