On Wed, 10 May 2006, Linus Torvalds wrote: > > - having the information in one place. I agree that the multi-file > approach works fine for shell scripts (although I disagree that the new > one would be harder - you just use git-repo-config instead), but I > think it's quite confusing from a new user perspective. Btw, I seriously believe that git has come to the point where we've licked the real technical issues. Stability hasn't been a concern for the last year - and even something as seriously as a repacking bug causing a SIGSEGV (yesterday) was actually basically designed to not be able to cause problems. The repack failed, and nothing happened to the old data. It was scary, but it wasn't "bad". The last performance problem was a stupid one-liner, where one of the shell scripts didn't use the "--aggressive" flag for doing the trivial three-way merge, so it ended up forking and executing the "merge-one-file" shell script for 4500+ files for one unfortunate project that had a strange workflow. Adding the "--aggressive" flag took a 5-minute (where all of the time was spent in a shell script basically doing nothing) thing down to under a second. So git should kick butt in performance, scale very well, and seems to take less disk space than just about anybody else. So what do people actually _complain_ about? I don't think we've seen a serious complaint lately that hasn't been about nice user interface and/or documentation. Anybody? So as far as I can tell, the #1 issue is that "new user" experience. You can pretty much forget about anything else. Working with git in a distributed manner is really easy and efficient, but from the comments I've seen, it's not always easy and obvious how to get to that point. Creating a remote repository and filling it. And being able to understand what the local vs remote branches actually _mean_. And I think our current .git/remotes/ thing is a part of that. It's not exactly user _hostile_, but it's very much "implementation friendly, and doesn't care about the user". So I think .git/config can help us there. I also think we could do with a few scripts to just do setup of a remote repo: git remote clone <remoteaddress> git remote branch <remoteaddress> [-D] git remote fsck <remoteaddress> git remote repack <remoteaddress> -a -d which would all basically boil down to "ssh to the remote address, cd into that directory, and do the named git command there" (well, not clone: doing a remote clone involves doing a mkdir/git-init-db/git-receive-pack remotely, and doing a git-send-pack locally, so some of them would be about doing things _both_ locally and remotely). And documentation. Now, I don't do documentation, and I really think somebody else could do the whole "git remote <cmd>" thing too. It _should_ really be pretty trivial. My real point is that almost none of this is about technology, and it's much more about trying to put a whole lot of lipstick on this pig. We have _got_ the technology already, and I think most people will agree git is doing pretty damn well there. Because I really think the pig is quite charming, just sometimes you see some of its boorish sides right now.. (Or should that be "boarish", when we talk about pigs? ;) Linus - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html