Thread (42 messages) 42 messages, 7 authors, 2021-06-17

Re: [PATCH 4/7] checkout: fix merge.conflictstyle handling

From: Phillip Wood <hidden>
Date: 2021-06-10 14:52:00

On 10/06/2021 15:11, Felipe Contreras wrote:
Phillip Wood wrote:
quoted
On 09/06/2021 20:28, Felipe Contreras wrote:
quoted
Currently both merge.conflictStyle and `git commit --merge
--conflict=diff3` don't work together, since the former wrongly
overrides the later.

The way merge configurations are handled is not correct.
It should be possible to do git_config(merge_recursive_config, ...) just
like we can with git_diff_basic_config and others.
It would be helpful to explain what the problem with
merge_recursive_config() actually is rather than just saying "it should
be possible ..."
The problem is that you can't do this:

   git_config(merge_recursive_config, NULL);

As it was explained.
You do not explain why you cannot do that
That is the problem. I don't know how that's not clear.
quoted
quoted
Therefore builtins like `git merge` can't call this function at the
right time.
  >
quoted
We shuffle the functions a little bit so at least merge_recursive_config
doesn't call git_xmerge_config directly and thus override previous
configurations.
Rather than papering of the problem, how difficult would it be to add a
field to ll_merge_options and pass the conflict style with that rather
than fiddling with the order that we set a global variable.
Probably not that difficult, but then we also need a parser that
converts from "diff3" to whatever values we decide in that new field. We
would need a new parse_config_conflict_style() function.
And that function will be only used by `git checkout` and nothing else.
So I don't think there's much value in it.
It would allow us to add a --conflict option to all the mergey commands 
in the future and would be much easier to reason about than the approach 
of juggling where we call git_xmerge_config(). This patch requires us to 
audit all the code paths that end up in merge_recursive_config() to make 
sure they now call git_xmerge_config() themselves. You don't seem to 
have done that as you don't know if am/apply are affected or not.


Best Wishes

Phillip
That problem whoever, is orthogonal to this series.
quoted
Does this change affect 'am/apply -3'? - Do they still read the config
setting properly?
Good question. I'll have to add more tests to make sure that works
properly.

Cheers.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help