On Thu, Mar 23, 2006 at 12:38:33PM -0800, Linus Torvalds wrote: > > lol, that sounds like a really good plan. Perhaps as a two pronged effort > > its worth changing the notion that git is primarily "plumbing". Adding > > some of the nice features of cogito and other "porcelains" into the core > > git might go a ways toward converting the few naysayers we don't kill. > > Actually, as far as I can tell, git already has a hell of a lot more > porcelain than pretty much any non-IDE type traditional SCM. Certainly > more than CVS. > > Yeah, I'm not counting things like Eclipse etc. I'm talking about "plain > SCM" environments, ie just basic SVN or CVS. What are we missing in that > department? (The only thing I can think of is a diff colorizer, which some > prople seem to really want). I'd like sunglasses with that diff colouriser, please ;-) For my various hacking projects and archiving needs git has done me alot of good and it's pretty close to the answer to the question for life, universe and everything. But a few rough areas (I'm currently using git 1.2.4 btw.) remain: o During the debugging phase before a new kernel release I put anything that isn't appropriate for the master branch on a queue branch which I am rebasing frequently to ensure things will work right in the "patch bombing" phase before the next -rc1 when I'm sending everything on the queue branch upstream. The problem: users pull such a branch, create their own branch starting somewhere on my queue branch. So eventually when they pull again after I rebased the branch things blow up spectactularly. This needs a simple solution. o git rebase had no reasonable handling of conflicts last I ran into a rebase conflict. o If a file is modified in a user's tree and a non-conflicting patch is being pull users seem to expect the old CVS behaviour which is trying to merge into the checked out tree, worst case adding conflict markers. Git just refuses the operation. o I had people piling up over 2GB in their $GIT_DIR/objects/pack/ directory because they were using the rsync method for updating. o Git is a dramatically more powerful and for most operations better performing SCM than CVS - but CVS is what people know, it's easy to learn and handling special cases like conflicts is sort of obvious because CVS expects the user to cleanup the mess and does not try to compete with the users in that. o A Git for Dummies book would be helpful. o When users have problems with git I found it useful to explain them how git internally works so they get a better understanding of what actually is going on. Dominic Sweetman which is an excellent technical writer has made a similar experience and started writing a bit about git in the wiki at http://www.linux-mips.org/wiki/WhatIsGit May somebody wants to extend this? (Dominic unfortunately is currently deeply burried in writing the 2nd issue of See MIPS Run, so can't really contribute ...) Ralf - : 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