Re: [PATCH v2 2/7] merge-ort: add some more explanations in collect_merge_info_callback()

From: Elijah Newren <newren@gmail.com>
Date: Jul 14, 2021, 00:19 UTC
Message-ID: <CABPp-BFBgCHAq=zWVoPPsDx04agDunAb3vVSgfJs4B2xVpasLg@mail.gmail.com>
In-Reply-To: <7f4fc9f6-9b46-6e39-1a66-b72e0c583f21@gmail.com>

On Tue, Jul 13, 2021 at 4:34 PM Bagas Sanjaya <bagasdotme@gmail.com> wrote:

Show 16 quoted lines

>
> On 14/07/21 02.32, Elijah Newren via GitGitGadget wrote:
> > @@ -1018,8 +1018,8 @@ static int collect_merge_info_callback(int n,
> >       if (side1_matches_mbase && side2_matches_mbase) {
> >               /* mbase, side1, & side2 all match; use mbase as resolution */
> >               setup_path_info(opt, &pi, dirname, info->pathlen, fullpath,
> > -                             names, names+0, mbase_null, 0,
> > -                             filemask, dirmask, 1);
> > +                             names, names+0, mbase_null, 0 /* df_conflict */,
> > +                             filemask, dirmask, 1 /* resolved */);
> >               return mask;
> >       }
> >
>
>
> Is df_conflict stands for directory-file conflict?

Yes, eventually propagating up to conflict_info->df_conflict, defined as:

    /* Whether this path is/was involved in a directory/file conflict */
    unsigned df_conflict:1;

Show 14 quoted lines

> >       /*
> > -      * Record information about the path so we can resolve later in
> > -      * process_entries.
> > +      * None of the special cases above matched, so we have a
> > +      * provisional conflict.  (Rename detection might allow us to
> > +      * unconflict some more cases, but that comes later so all we can
> > +      * do now is record the different non-null file hashes.)
> >        */
> >       setup_path_info(opt, &pi, dirname, info->pathlen, fullpath,
> >                       names, NULL, 0, df_conflict, filemask, dirmask, 0);
> >
>
> So when none of special cases matched, we assumed there's conflict
> (although provisional), right?

Yes, the "provisional" adjective in particular is there because we revisit each case in process_entries(), and resolve those that can be via content merges, renormalization, etc. The content merges need to wait until after rename detection allows us to pair up different files. If the different file versions are still not resolved after process_entries() then it becomes an actual conflict rather than just a provisional conflict.