Miklos Vajna <vmiklos@xxxxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
