From: Linus Torvalds Date: Mon, 06 Jun 2005 06:57:07 GMT Subject: Re: Last mile for 1.0 Message-ID: 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.. > > 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. > > 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