The big git command renaming..

The big git command renaming..

[Linus Torvalds]

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

Re: The big git command renaming..

[Dave Jones]

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

[PATCH] The big git command renaming fallout fix.

[Junio C Hamano]

>>>>> "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");

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

[Junio C Hamano]

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)

Re: The big git command renaming..

[H. Peter Anvin]

Dave Jones wrote:
> 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

Re: The big git command renaming..

[Linus Torvalds]

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

Re: The big git command renaming..

[H. Peter Anvin]

Linus Torvalds wrote:
> 
> 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

Re: The big git command renaming..

[Linus Torvalds]

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

Re: The big git command renaming..

[H. Peter Anvin]

Linus Torvalds wrote:
> 
> 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

Re: The big git command renaming..

[Nicolas Pitre]

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