Re: [PATCH] Build in merge

Miklos Vajna [off-list ref] 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.

quoted

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.