From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Wed, 09 Nov 2005 23:43:04 GMT
Subject: Re: Expected Behavior?
Message-ID: <46a038f90511091543h520f6a84k3e3b14c2e502989f@mail.gmail.com>
In-Reply-To: <20051109231248.GL16061@pasky.or.cz>

On 11/10/05, Petr Baudis <pasky@suse.cz> wrote:
> what mechanism are you talking about?

I suspect you haven't seen the git-merge mechanism in action -- or
perhaps I'm a bit lost and we're talking about different things. At
least last time I merged with git-merge.sh, it tried several
strategies in order in a temporary index. Actually, it tried in order:
stupid, resolve, recursive... It shortcuts if one merges cleanly, but
it'll definitely work through them. It's very nice to see this in
action.

> All the scripts have it hardcoded

Well, no. git-merge -s 'foo' works pretty well and isn't hardcoded.
Even if we agree on defaulting to only one relatively smart merger for
simplicity's sake, the mechanism we have in git-merge.sh (thanks to
Junio I think) is excellent, and should be kept. Linus will probably
do his merges with "stupid resolve" or just "stupid" and the rest of
us will use something else.

The mergers and things like git-merge-base are probably the areas of
git that need the most focus and polish -- that's why I'm
uncomfortable with cg-merge doing its own thing, as it gets a lot less
review than git-merge-XX resolvers.

Right now I am seeing some slightly abnormal things (*) in how some
our our merges are going, so I' ll have to roll up my sleeves at some
point and try and figure out what's going on. And as I look into
cg-merge and cg-Xmergefile, not many eyes have been through it...

* - (nothing serious, just an annoying tendency to show spurious
conflicts with the mergebase commit itself)

cheers,


martin