Re: MinGW port - initial work uploaded

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 24, 2007, 01:57 UTC
Message-ID: <Pine.LNX.4.63.0701240251230.22628@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <7vlkjtkxlm.fsf@assigned-by-dhcp.cox.net>

Hi,

On Tue, 23 Jan 2007, Junio C Hamano wrote:

Show 20 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Linus wrote:
> >
> >> All the other uses seem to be just a case of
> >> 
> >> 	git-merge-index -o git-merge-one-file -a
> >> 
> >> and wouldn't it be beautiful if the default action for git-merge-index (if 
> >> you do _not_ specify a merger program) was to do the simple one-file 
> >> three-way merge that we can already do for real merges?
> >
> > If you think that's a new dream:
> >
> > http://article.gmane.org/gmane.comp.version-control.git/32046/match=git-merge-one-file
> 
> I've thought about it when I was really bored, but noticed that we have 
> no serious users of git-merge-index/git-merge-one-file combinations 
> anymore in-tree (octopus does not count, and it is trivial to make it 
> use merge-recursive if somebody is twisted enough).

Hah! You just pulled the last serious user! That's cheating.

Seriously again, the users of merge-index are

(git-checkout, which you pulled) git-merge, which I do not really understand git-merge-octopus, which you already discussed git-merge-resolve, which is (hopefully) superseded by -recursive git-merge-stupid, which is stupid git-resolve, which is deprecated.

What I am nervous about is git-merge. I do not even fully understand in which circumstances it calls merge-index at all. (Too tired to read that now, anyway.)

Ciao, Dscho