Re: [PATCH 4/7] checkout: fix merge.conflictstyle handling
- From
- Phillip Wood <phillip.wood123@gmail.com>
- Date
- Jun 10, 2021, 14:50 UTC
- Message-ID
- <49da6d73-c49f-d75e-0eb2-b12bd529fcfa@gmail.com>
- In-Reply-To
- <60c21d9ce8848_b25b120884@natae.notmuch>
On 10/06/2021 15:11, Felipe Contreras wrote:
Show 19 quoted lines
> Phillip Wood wrote: >> On 09/06/2021 20:28, Felipe Contreras wrote: >>> 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
Show 18 quoted lines
> That is the problem. I don't know how that's not clear. > >>> Therefore builtins like `git merge` can't call this function at the >>> right time. >> > >>> 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
Show 10 quoted lines
> That problem whoever, is orthogonal to this series. > >> 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. >