threads / discuss / 396

The big git command renaming..

Subject: The big git command renaming..

## tl;dr

10 messages between Apr 29, 2005 and Apr 30, 2005.

replies: 9people: 5as markdown or json

Linus Torvalds· Apr 29, 2005, 21:24 UTC · lore

Ok, I hate to do this, since my fingers have already gotten used to the old names, but we clearly can't continue to use command names like "update-cache" or "read-tree" that are totally non-git-specific.

So I just pushed out a change that renames the commands to always have a "git-" prefix. In addition, I renamed "show-diff" to "diff-files", with together with the prefix means that it becomes "git-diff-files" when used.

Since I end up using tab-completion for almost all my work, and since -within- the source directory there's no confusion, I didn't actually name the source files with any git- prefix. Quite the reverse: I removed the prefix from the two .c files that already had it (so git-mktag.c is now just "mktag.c"), and the general rule for building the executable from a C file is now

	git-%: %.c $(LIB_FILE)
		$(CC) $(CFLAGS) -o $@ $(filter %.c,$^) $(LIBS)

this seemed to be a nice regular interface that means that binaries get installed with clear "git-" prefixes, but that I don't have to look at them when I edit the sources.

Sorry to everybody else whose fingers have already learnt the old names. The good news is that if you use cogito, you won't care.

		Linus
Dave Jones· Apr 29, 2005, 21:35 UTC · re: Linus Torvalds · lore

Re: The big git command renaming..

On Fri, Apr 29, 2005 at 02:24:43PM -0700, Linus Torvalds wrote:
 > 
 > Ok, I hate to do this, since my fingers have already gotten used to the 
 > old names, but we clearly can't continue to use command names like 
 > "update-cache" or "read-tree" that are totally non-git-specific.
 > 
 > So I just pushed out a change that renames the commands to always have a 
 > "git-" prefix. In addition, I renamed "show-diff" to "diff-files", with 
 > together with the prefix means that it becomes "git-diff-files" when used.
 > 
 > Since I end up using tab-completion for almost all my work, and since
 > -within- the source directory there's no confusion, I didn't actually name
 > the source files with any git- prefix. Quite the reverse: I removed the
 > prefix from the two .c files that already had it (so git-mktag.c is now
 > just "mktag.c"), and the general rule for building the executable from a C 
 > file is now
 > 
 > 	git-%: %.c $(LIB_FILE)
 > 		$(CC) $(CFLAGS) -o $@ $(filter %.c,$^) $(LIBS)
 > 
 > 
 > this seemed to be a nice regular interface that means that binaries get 
 > installed with clear "git-" prefixes, but that I don't have to look at 
 > them when I edit the sources.

Can you push out a new tarball to kernel.org too please, to kill some potential confusion in documentation/scripts ?

		Dave
H. Peter Anvin· Apr 29, 2005, 21:58 UTC · re: Dave Jones · lore

Re: The big git command renaming..

Dave Jones wrote:
Show 27 quoted lines
> On Fri, Apr 29, 2005 at 02:24:43PM -0700, Linus Torvalds wrote:
>  > 
>  > Ok, I hate to do this, since my fingers have already gotten used to the 
>  > old names, but we clearly can't continue to use command names like 
>  > "update-cache" or "read-tree" that are totally non-git-specific.
>  > 
>  > So I just pushed out a change that renames the commands to always have a 
>  > "git-" prefix. In addition, I renamed "show-diff" to "diff-files", with 
>  > together with the prefix means that it becomes "git-diff-files" when used.
>  > 
>  > Since I end up using tab-completion for almost all my work, and since
>  > -within- the source directory there's no confusion, I didn't actually name
>  > the source files with any git- prefix. Quite the reverse: I removed the
>  > prefix from the two .c files that already had it (so git-mktag.c is now
>  > just "mktag.c"), and the general rule for building the executable from a C 
>  > file is now
>  > 
>  > 	git-%: %.c $(LIB_FILE)
>  > 		$(CC) $(CFLAGS) -o $@ $(filter %.c,$^) $(LIBS)
>  > 
>  > 
>  > this seemed to be a nice regular interface that means that binaries get 
>  > installed with clear "git-" prefixes, but that I don't have to look at 
>  > them when I edit the sources.
> 
> Can you push out a new tarball to kernel.org too please, to kill
> some potential confusion in documentation/scripts ?

Oh yes, and can that tarball please be put in /pub/software/scm/git, and the associated git tree be moved to /pub/scm/git?

	-hpa
Linus Torvalds· Apr 29, 2005, 22:14 UTC · re: H. Peter Anvin · lore

Re: The big git command renaming..

On Fri, 29 Apr 2005, H. Peter Anvin wrote:
> 
> Oh yes, and can that tarball please be put in /pub/software/scm/git, and 
> the associated git tree be moved to /pub/scm/git?
Sure. 
Just a quick question: what are the "rules" for /pub/scm/git?

Should I put just git in it, or is it meant for any "git project", and should I also copy the 2.6.x kernel home from

	/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
to
	/pub/scm/git/linux-2.6.git
or what?
Me, I can do either or both, I just don't know what the intent was..
		Linus
H. Peter Anvin· Apr 29, 2005, 23:09 UTC · re: Linus Torvalds · lore

Re: The big git command renaming..

Linus Torvalds wrote:
Show 17 quoted lines
> 
> Sure. 
> 
> Just a quick question: what are the "rules" for /pub/scm/git? 
> 
> Should I put just git in it, or is it meant for any "git project", and
> should I also copy the 2.6.x kernel home from
> 
> 	/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> 
> to
> 
> 	/pub/scm/git/linux-2.6.git
> 
> or what?
> 
> Me, I can do either or both, I just don't know what the intent was..
/pub/scm/git I created for your git project; don't move the kernel in there.

If you have any other non-kernel git projects, just let me know and I'll make directories for them.

	-hpa

P.S. Are you still updating the trees in /pub/linux/kernel/people/torvalds/? They still show up on our change reports, and cause problems for the mirrors. Perhaps you could replace those trees with symlinks into /pub/scm.

	-hpa
Linus Torvalds· Apr 29, 2005, 23:39 UTC · re: H. Peter Anvin · lore

Re: The big git command renaming..

On Fri, 29 Apr 2005, H. Peter Anvin wrote:
> 
> If you have any other non-kernel git projects, just let me know and I'll 
> make directories for them.

The others are small and specialized (sparse, and the "git-tools" thing, and the latter is so much smaler than my BK tools used to be that I suspect I should just move it into git as the "apply mbox" import thing it is)

> P.S. Are you still updating the trees in 
> /pub/linux/kernel/people/torvalds/?  They still show up on our change 
> reports, and cause problems for the mirrors.  Perhaps you could replace 
> those trees with symlinks into /pub/scm.
Fixed.
		Linus
H. Peter Anvin· Apr 29, 2005, 23:42 UTC · re: Linus Torvalds · lore

Re: The big git command renaming..

Linus Torvalds wrote:
Show 12 quoted lines
> 
> On Fri, 29 Apr 2005, H. Peter Anvin wrote:
> 
>>If you have any other non-kernel git projects, just let me know and I'll 
>>make directories for them.
> 
> 
> The others are small and specialized (sparse, and the "git-tools" thing,
> and the latter is so much smaler than my BK tools used to be that I
> suspect I should just move it into git as the "apply mbox" import thing it
> is)
>

I created /pub/scm/devel/sparse to go along with /pub/software/devel/sparse. I agree with git-tools; just put it in the git directory (after all, you can have more than one dir.git underneath it.)

	-hpa
Junio C Hamano· Apr 29, 2005, 21:41 UTC · re: Linus Torvalds · lore

[PATCH] The big git command renaming fallout fix.

>>>>> "LT" == Linus Torvalds <torvalds@osdl.org> writes:
LT> Ok, I hate to do this, ...
Well, it was time.  This fixes the git-export which calls diff-tree.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
cd /opt/packrat/playpen/public/in-place/git/git.linus/
show-diff -p export.c
--- k/export.c  (mode:100644)
+++ l/export.c  (mode:100644)
@@ -18,7 +18,7 @@ void show_commit(struct commit *commit)
 		char *against = sha1_to_hex(commit->parents->item->object.sha1);
 		printf("\n\n======== diff against %s ========\n", against);
 		fflush(NULL);
-		sprintf(cmdline, "diff-tree -p %s %s", against, hex);
+		sprintf(cmdline, "git-diff-tree -p %s %s", against, hex);
 		system(cmdline);
 	}
 	printf("======== end ========\n\n");
Junio C Hamano· Apr 29, 2005, 21:53 UTC · re: Junio C Hamano · lore

[PATCH] Makefile: The big git command renaming fallout fix.

Here is another.  This one belongs to a clean-up category.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
cd /opt/packrat/playpen/public/in-place/git/git.linus/
show-diff -p Makefile
--- k/Makefile  (mode:100644)
+++ l/Makefile  (mode:100644)
@@ -59,8 +59,6 @@ CFLAGS += '-DSHA1_HEADER=$(SHA1_HEADER)'
 $(LIB_FILE): $(LIB_OBJS)
 	$(AR) rcs $@ $(LIB_OBJS)
 
-init-db: init-db.o
-
 git-%: %.c $(LIB_FILE)
 	$(CC) $(CFLAGS) -o $@ $(filter %.c,$^) $(LIBS)
 
@@ -104,6 +102,7 @@ read-cache.o: $(LIB_H)
 sha1_file.o: $(LIB_H)
 usage.o: $(LIB_H)
 diff.o: $(LIB_H)
+strbuf.o: $(LIB_H)
 
 clean:
 	rm -f *.o mozilla-sha1/*.o ppc/*.o $(PROG) $(LIB_FILE)
Nicolas Pitre· Apr 30, 2005, 14:24 UTC · re: Linus Torvalds · lore

Re: The big git command renaming..

On Fri, 29 Apr 2005, Linus Torvalds wrote:
> So I just pushed out a change that renames the commands to always have a 
> "git-" prefix. In addition, I renamed "show-diff" to "diff-files", with 
> together with the prefix means that it becomes "git-diff-files" when used.
While at it, could you also rename show-files to ls-files?
Nicolas

← back to recent threads