Re: Last mile for 1.0

From: Thomas Glanzmann <sithglan@stud.uni-erlangen.de>
Date: Jun 6, 2005, 07:01 UTC
Message-ID: <20050606070131.GD3669@cip.informatik.uni-erlangen.de>
In-Reply-To: <Pine.LNX.4.58.0506052351470.1876@ppc970.osdl.org>

Hello,

> The thing is, I historically _often_ have uncommitted data, and it's been 
> one of the biggest bummers for me that a merge of a totally unrelated 
> thing will crap all over my debugging patch..

got the point. I useally work like that, too. But I never did it with a distributed SCM just with CVS.

> If he uses the same index file, he'll be protected by the index lock.

I see.

> Not exactly. It updates the index directly, without necessarily updating 
> the working directory. For example:

> 	"$1.." | "$1.$1" | "$1$1.")
> 	        echo "Removing $4"
> 	        exec git-update-cache --force-remove "$4" ;;

> it _says_ "removing $4", but it never actually does so, so the working 
> directory still has the file ;)

> Same goes with added files or even updated files, where it uses
> "--cacheinfo" to update the cache without even touching the working
> directory.

Now I see your point.

> Anyway, git-resovle-script needs to be made to use "git-merge-cache
> -o" too, methinks. And it needs a test-case or two.

Yes, it does. In my merge script in perl it already does that. :-)

	Thomas