Re: [PATCH] Build in merge

[Junio C Hamano <gitster@pobox.com>]

Miklos Vajna <vmiklos@frugalware.org> writes:

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

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