Re: Please undo "Use git-merge instead of git-resolve in git-pull"

From: David S. Miller <davem@davemloft.net>
Date: Sep 22, 2005, 00:28 UTC
Message-ID: <20050921.172849.103555057.davem@davemloft.net>
In-Reply-To: <Pine.LNX.4.58.0509211501130.2553@g5.osdl.org>

From: Linus Torvalds <torvalds@osdl.org>
Date: Wed, 21 Sep 2005 15:03:39 -0700 (PDT)

Show 8 quoted lines

> I've always multi-tasked, but when I started git I was ready to drop it. 
> Then I came up with that wonderful "merge in the index" approach, and I 
> could do it again, and I was _soo_ happy.
> 
> I often have local changes in my tree that I don't want to commit but that 
> I'm testing out. Havign them interfere with merging other peoples work 
> would mean that I'd have to have a totally separate tree for that, which I 
> could do, but I'm much much happier not having to.

You know, I personally was unaware that this was supported until now. I have been always reverting local debugging changes in order to merge other people's work in, then reapply the debugging changes afterwards.

I guess I won't have to do that any more. :-)

So as long as they don't interfere, you can keep local debugging changes out of GITs way for just about anything right? For example, as long as you don't "git-update-cache foo.c" those files in your local debugging hack, you can just "git commit" afterwards and only put in the changes you want. It won't myseriously find those modified files and what to do something with them right?

This goes with the idea that GIT only works with what you tell it about, I suppose.