Antonin Delpeuch <antonin@xxxxxxxxxxx> writes: > After more testing (combining custom merge drivers with rerere) I > realized that my patch can lead to a segmentation error. Many > apologies for not having caught that earlier! Ah, understandable. The 3-way merge machinery may not even have to work on commit objects (it can merge two trees, using another tree as the "common ancestor" tree, just fine). And in such a case, it is perfectly possible there is no "human readable name"; all there is may be a tree object name. > On 18/01/2024 23:09, Antonin Delpeuch via GitGitGadget wrote: >> @@ -222,6 +222,12 @@ static enum ll_merge_result ll_ext_merge(const struct ll_merge_driver *fn, >> strbuf_addf(&cmd, "%d", marker_size); >> else if (skip_prefix(format, "P", &format)) >> sq_quote_buf(&cmd, path); >> + else if (skip_prefix(format, "S", &format)) >> + sq_quote_buf(&cmd, orig_name); >> + else if (skip_prefix(format, "X", &format)) >> + sq_quote_buf(&cmd, name1); >> + else if (skip_prefix(format, "Y", &format)) >> + sq_quote_buf(&cmd, name2); > > The "orig_name", "name1" and "name2" pointers can be NULL at this > stage. This can happen when the merge is invoked from rerere, to > resolve a conflict using a previous resolution. sq_quote_buf(&cmd, name1 ? name1 : "(ours)"); or something like that, perhaps.
