Re: Last mile for 1.0

From: Thomas Glanzmann <sithglan@stud.uni-erlangen.de>
Date: Jun 6, 2005, 06:44 UTC
Message-ID: <20050606064456.GC3669@cip.informatik.uni-erlangen.de>
In-Reply-To: <Pine.LNX.4.58.0506052300350.1876@ppc970.osdl.org>

Hello,

> Well, there was actually a much more fundamental problem, which is that 
> the merge script depended on being able to do

> 	git-checkout-cache -f -u -a

> which in turn obviously meant that _whatever_ it did, it would end up 
> overwriting any dirty state in the working tree.

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:

git-diff-files -z -r (but ignore the deleted) git-diff-cache -r --cached HEAD

> And you can't remove the git-checkout-cache, because after the merge we've 
> lost the original state anyway, so there's no way to know whether whatever 
> you had in the working directory was dirty or not.

Show 8 quoted lines

> So I've actually been working now to make the very low-level git-read-tree 
> Do The Right Thing (tm), and I think I'm getting there. It basically 
> depends on "git-read-tree" noticing when the state is dirty enough that we 
> can't safely do the merge, and then for the safe cases it can actually 
> update anything it merged properly. As a result, there's never any need 
> for git-checkout-cache, and the only thing that needs updating in the 
> working directory is the stuff that we end up merging by hand _outside_ of 
> git-read-tree.

Show 5 quoted lines

> There's two cases: fast-forward and a real merge. And the thing is, to do 
> even just the fast-forward safely, it actually needs to know what the base 
> tree was (otherwise it can only tell that the file was up-to-date in the 
> index, but it can't know whether the index actually matched the original 
> HEAD..). So now the fast-forward case is actually a two-way merge:

> 	git-read-tree -u -m HEAD NEW_HEAD

> where "-u" stands for "update", and tells read-tree that it should check 
> out the files it merges up.

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

> But for a file that wasn't touched at all by the merge, we can leave it
> dirty in the index, since whatever dirty index state was valid before the
> merge is obviously valid after it too. So now you can have dirty state in 
> your tree, and merges will complain only if it matters to them.

Nice to have. :-)

> ...

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

	Thomas