On Tue, Jul 13, 2021 at 4:34 PM Bagas Sanjaya <bagasdotme@xxxxxxxxx> wrote:
>
> 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;
> > /*
> > - * 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.
