Re: [PATCH] Build in merge

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 8, 2008, 01:05 UTC
Message-ID: <7vskulxk0o.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20080708010007.GA10347@genesis.frugalware.org>

Miklos Vajna <vmiklos@frugalware.org> writes:

Show 6 quoted lines

> I could imagine the following situations:
>
> 1) A project has code in a repo, some documentation and po files.
>
> The first two can be merged with builtin strategies, the later probably
> needs a custom merge driver.

Per-path merge is probably better handled with custom ll-merge driver anyway. See gitattributes(5).

> 2) Someone is not happy with the current recursive strategy and writes
> from scratch a new one. He/she puts it to pull.twohead, so it will be
> tried before recursive.

That is fine.

> To sum up: I am not sure what would be the benefit of being able to
> specify flags for strategies. However, if we want so, it would be good
> to discuss how it should be done.

It wasn't *me* ;-) who wanted to add these "flags".

I think it does not matter what "my-strategy" does unless "-s my-strategy" (or pull.twohead) is explicitly given by the user, and at that time, DEFAULT_* options should not matter. It probably is Ok to allow fast forward and trivial merges to them. We'll see.

Show 11 quoted lines

>> The part that records which strategies were specified from the command
>> line *in what order* via "-s foo" switches should remain list of pointers
>> into "struct strategy", which is called "struct strategy **use_strategies"
>> in the code and corresponds to the $use_strategies variable in the
>> scripted version.  The order of these is important, as that defines in
>> which order the strategies are tried [*1*].  If you go route (1), these
>> pointers will all be pointing at elements in all_strategies[]; with route
>> (2) they may be pointing at either all_strageties[] element or
>> user_strategies[] element.
>
> I see the problem, I lost the order at the moment.

That's Ok.  See the other patch on top of your previous one.