Re: Last mile for 1.0

From: Linus Torvalds <torvalds@osdl.org>
Date: Jun 6, 2005, 06:57 UTC
Message-ID: <Pine.LNX.4.58.0506052351470.1876@ppc970.osdl.org>
In-Reply-To: <20050606064456.GC3669@cip.informatik.uni-erlangen.de>

On Mon, 6 Jun 2005, Thomas Glanzmann wrote:

> 
> true. But I don't see the problem. Just ensure that there are no
> uncommitted data and no dirty files before proceeding with the merge by
> calling:

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

Show 8 quoted lines

> > And now git-read-tree also tries to be very careful: if one of the files 
> > that needs to be updated is already dirty, or it doesn't match the 
> > original HEAD, then git-read-tree will just exit with an error and not do 
> > anything at all.
> 
> Now I see your point. And a cmp-and-xchg HEAD would be useful here, too.  What
> if a user tries to shoot himself in the head by pull from two trees
> simultaneous?

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

Show 6 quoted lines

> > And the "git-merge-one-file-script" thing needs to be updated to keep the
> > tree updated as it merges things by hand, since it can't depend on the
> > git-checkout-cache fixing things up any more. Anybody?
> 
> I can't follow you there. AFAIK it retrieves all his files from
> git-merge-cache and just calls git-update-cache to update the index.

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.

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

		Linus