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 ...
[ message continues ]

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

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

-

[ message continues ]

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

Best regards,
-- 
Yann
-

[ message continues ]

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.




-

[ message continues ]

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
-

[ message continues ]

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?


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.


-

[ message continues ]

Hi,


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

-

[ message continues ]

Ok, please consider the idea sold.

-

[ message continues ]

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


Nicolas
-

[ message continues ]

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.


-

[ message continues ]

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 ...
[ message continues ]

That's exactly why we have told people to use plumbing in their

But that would break existing scripts wouldn't it?

-

[ message continues ]

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.


-

[ message continues ]

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
-

[ message continues ]

Hi,


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

-

[ message continues ]

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

-

[ message continues ]

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.


-

[ message continues ]

Hi,


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

-

[ message continues ]

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.


-

[ message continues ]

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

Best regards,
-- 
Yann
-

[ message continues ]