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

Subsystems: kernel build + files below scripts/ (unless maintained elsewhere), the rest

5 messages, 4 authors, 2016-06-15 · open the first message on its own page

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

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: 2016-06-15 22:43:19

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"

From: walt <hidden>
Date: 2016-06-15 22:43:19

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"

From: Johannes Schindelin <hidden>
Date: 2016-06-15 22:43:19

Hi,

On Sat, 30 Jun 2007, walt wrote:
Linus Torvalds wrote:
quoted
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"

From: walt <hidden>
Date: 2016-06-15 22:43:19

Johannes Schindelin wrote:
Hi,

On Sat, 30 Jun 2007, walt wrote:
quoted
Linus Torvalds wrote:
quoted
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"

From: Yann Dirson <hidden>
Date: 2016-06-15 22:43:19

On Sat, Jun 30, 2007 at 10:37:07PM +0100, Johannes Schindelin wrote:
Hi,

On Sat, 30 Jun 2007, walt wrote:
quoted
Linus Torvalds wrote:
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help