From: Fredrik Kuivinen <freku045@student.liu.se>
Date: Tue, 13 Sep 2005 20:33:06 GMT
Subject: Re: [RFH] Merge driver
Message-ID: <20050913203252.GA1737@c165.ib.student.liu.se>
In-Reply-To: <7vmzmi9ebj.fsf@assigned-by-dhcp.cox.net>

On Mon, Sep 12, 2005 at 02:16:48PM -0700, Junio C Hamano wrote:
> Fredrik Kuivinen <freku045@student.liu.se> writes:
> 
> > git-read-tree A
> > git-update-cache --refresh
> > git-read-tree -u -m T A B
> >
> > We need the second step because otherwise git-read-tree will complain
> > that the cache isn't uptodate. But we _know_ that the contents are
> > uptodate, so the second step is unnecessary and just eats time.
> 
> If we _know_ it should match, isn't there a way to tell the
> first "git-read-tree A" not to mess with the dirtiness, like,
> ah, one-way merge?
> 

I don't think a one way merge will do what we want in this case.

At the start of the merge we know that the working directory is in
sync with the index. But during the merge we will merge the common
ancestors, and the index file will be overwritten. When we are done
with merging the common ancestors we want to merge the heads that we
wanted to merge from the begining (A and B) using T as the common
ancestor. When 'git-read-tree A' is executed we get a cache which has
zeroed stat data, but SHAs and mode information which match the
working directory. If we do 'git-update-cache --refresh' the stat data
will be updated to match the working directory.

Using 'git-read-tree -m A' will not work because the stat data in the
cache is zeroed before we run this command.

I see two solutions, either allow passing '-i' together with '-u' to
git-read-tree or use a temporary index file when we are merging the
common ancestors.

Thinking a bit more about it, maybe it's better to use a temporary
index file. If go this way we could, at least in principle, allow
merges which starts with a dirty working directory.

- Fredrik