Re: Errors GITtifying GCC and Binutils

From: Ralf Baechle <ralf@linux-mips.org>
Date: Mar 24, 2006, 12:32 UTC
Message-ID: <20060324123238.GA3070@linux-mips.org>
In-Reply-To: <Pine.LNX.4.64.0603231134160.26286@g5.osdl.org>

On Thu, Mar 23, 2006 at 12:38:33PM -0800, Linus Torvalds wrote:

Show 13 quoted lines

> > 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