git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 6/7] merge-ort: add die-not-implemented stub handle_content_merge() function

From
Elijah Newren <newren@gmail.com>
Date
Dec 3, 2020, 19:56 UTC
Message-ID
<CABPp-BFytQ5d2s8VpMbNXDGzG3=Jd2Tm2=G_mh+OBYqzhDeHBg@mail.gmail.com>
In-Reply-To
<8e861bc8-4da1-01aa-7de6-c6c128590170@gmail.com>
On Thu, Dec 3, 2020 at 10:40 AM Derrick Stolee <stolee@gmail.com> wrote:
Show 48 quoted lines
>
> On 12/3/2020 10:59 AM, Elijah Newren via GitGitGadget wrote:
> > From: Elijah Newren <newren@gmail.com>
> >
> > This simplistic and weird-looking patch is here to facilitate future
> > patch submissions.  Adding this stub allows rename detection code to
> > reference it in one patch series, while a separate patch series can
> > define the implementation, and then both series can merge cleanly and
> > work nicely together at that point.
> >
> > Signed-off-by: Elijah Newren <newren@gmail.com>
> > ---
> >  merge-ort.c | 14 ++++++++++++++
> >  1 file changed, 14 insertions(+)
> >
> > diff --git a/merge-ort.c b/merge-ort.c
> > index e653ba35ea..e7220cbbb4 100644
> > --- a/merge-ort.c
> > +++ b/merge-ort.c
> > @@ -523,6 +523,18 @@ static int collect_merge_info(struct merge_options *opt,
> >
> >  /*** Function Grouping: functions related to threeway content merges ***/
> >
> > +static int handle_content_merge(struct merge_options *opt,
> > +                             const char *path,
> > +                             const struct version_info *o,
> > +                             const struct version_info *a,
> > +                             const struct version_info *b,
> > +                             const char *pathnames[3],
> > +                             const int extra_marker_size,
> > +                             struct version_info *result)
> > +{
> > +     die("Not yet implemented");
> > +}
> > +
> >  /*** Function Grouping: functions related to detect_and_process_renames(), ***
> >   *** which are split into directory and regular rename detection sections. ***/
> >
> > @@ -919,6 +931,8 @@ static void process_entry(struct merge_options *opt,
> >               ci->merged.clean = 0;
> >               ci->merged.result.mode = ci->stages[1].mode;
> >               oidcpy(&ci->merged.result.oid, &ci->stages[1].oid);
> > +             /* When we fix above, we'll call handle_content_merge() */
> > +             (void)handle_content_merge;
>
> I'm not exactly sure what the value is of this line. Is it just to
> make sure we have a reference to the 'static' method without actually
> calling it anywhere?

Yes; without the reference the compiler fails with an unused function error message. I know it's not used yet, but I really need it there, so I have to fake the compiler out with a lame expression (take the address of the function, cast to void, and discard the result since I don't assign it anywhere or anything).

> "weird-looking patch" indeed! I'm more confused than anything.

In general, rename detection occurs before process_entry() and thus process_entry() can handle the content merging. However, some unusual rename conflicts require multiple content merges (and possibly result in nested conflict markers) and so the rename code needs to be able to call handle_content_merge() for the first of those.

I really wanted to split apart the series for rename detection (12 patches), and the one for more conflict handling (10 patches), especially since the latter series includes 6 patches for building up handle_content_merge() (3 for regular file content merging and another 3 for submodule "merging"). The two series are nearly orthogonal, but I had to somehow allow the rename side to call handle_content_merge() without having both series try to introduce the same function. Hence this patch.

Previous: Derrick StoleeNext: Elijah Newren via GitGitGadget
Message 10 of 13 in “merge-ort: some groundwork for further implementation”
  1. 0/7 merge-ort: some groundwork for further implementationElijah Newren via GitGitGadget, Dec 3, 2020
  2. 3/7 merge-ort: add a path_conflict field to merge_options_internalElijah Newren via GitGitGadget, Dec 3, 2020
  3. 2/7 merge-ort: add a clear_internal_opts helperElijah Newren via GitGitGadget, Dec 3, 2020
  4. Derrick StoleeDec 3, 2020
  5. 4/7 merge-ort: add a paths_to_free field to merge_options_internalElijah Newren via GitGitGadget, Dec 3, 2020
  6. 5/7 merge-ort: add function grouping commentsElijah Newren via GitGitGadget, Dec 3, 2020
  7. 1/7 merge-ort: add a few includesElijah Newren via GitGitGadget, Dec 3, 2020
  8. 6/7 merge-ort: add die-not-implemented stub handle_content_merge() functionElijah Newren via GitGitGadget, Dec 3, 2020
  9. Derrick StoleeDec 3, 2020
  10. Elijah NewrenDec 3, 2020
  11. 7/7 merge-ort: add modify/delete handling and delayed output processingElijah Newren via GitGitGadget, Dec 3, 2020
  12. Derrick StoleeDec 4, 2020
  13. Elijah NewrenDec 4, 2020

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.