Thread (11 messages) flat view 11 messages, 6 authors, 2016-06-15

Re: [PATCH 0/2] Make gc a builtin.

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


On Mon, 12 Mar 2007, Theodore Tso wrote:
I'm not sure I understand the portability argument?  All of the
platforms that git currently supports will handle shell scripts,
right?  
Git "supports" MinGW, or at least wants to. And yes, you can put bash in 
there, but we'd be *so* much better off if we had no shell scripting at 
all.

Another thing I find annoying (even as a UNIX user) is that whenever I do 
any tracing for performance data, shell is absolutely horrid. It's *so* 
much nicer to do 'strace' on built-in programs that it's not even funny.

It's also sad how many performance issues we've had with shell, just 
because even something really simple (like a few hundred refs) is just too 
slow for shell scripting.
Heck, git-commit is still a shell script, and that's a rather, ah,
fundamental command, isn't it? 
Yeah, and that's probably my pet peeve. I'd love to see a built-in "git 
commit" and "git fetch". The "fetch--tool" thing in next gets rid of some 
of the latter (and apparently the worst performance problems), but it's 
sad how we have a really nice builtin "push", but our "fetch" is still 
mostly really hairy shell-code (not just "git-fetch.sh" itself, but 
"git-parse-remote.sh".

A gold star for whoever gets rid of any of of commit/clone/fetch or 
ls-remote

(ls-remote isn't that big or hairy, but I mention it because it's a user 
of "parse-remote", so making even just ls-remote built-in is probably 
going to help with fetch/clone eventually).

		Linus
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help