Re: [PATCH v2 09/20] merge-ort: record stage and auxiliary info for every path
- From
Derrick Stolee <stolee@gmail.com>
- Date
- Nov 11, 2020, 15:26 UTC
- Message-ID
- <94bf9b69-5d13-c914-fb1a-bce912018a63@gmail.com>
- In-Reply-To
- <20201102204344.342633-10-newren@gmail.com>
On 11/2/2020 3:43 PM, Elijah Newren wrote:
Show 14 quoted lines
> +static void setup_path_info(struct merge_options *opt,
> + struct string_list_item *result,
> + const char *current_dir_name,
> + int current_dir_name_len,
> + char *fullpath, /* we'll take over ownership */
> + struct name_entry *names,
> + struct name_entry *merged_version,
> + unsigned is_null, /* boolean */
> + unsigned df_conflict, /* boolean */
> + unsigned filemask,
> + unsigned dirmask,
> + int resolved /* boolean */)
> +{
> + struct conflict_info *path_info;In addition to my concerns below about 'conflict_info' versus 'merged_info', I was doubly confused that 'result' in the parameter list is given a variable named 'pi' for "path info" and result->util eventually is equal to this path_info. What if we renamed 'result' to 'pi' for "path info" here, then operated on 'pi->util' in this method?
> + path_info = xcalloc(1, resolved ? sizeof(struct merged_info) : > + sizeof(struct conflict_info));
Hm. I'm happy to have a `struct merged_info *` pointing to a `struct conflict_info`, but the opposite seems very dangerous. Perhaps we should always use sizeof(struct conflict_info)?
We can use path_info->merged.clean to detect whether the rest of the data is worth looking at. (Or, in your case, whether or not it is allocated.)
I imagine that in a large repo we will need many of these structs, but very few of them will actually need to be conflicts, so using 'struct conflict_info' always will lead to memory bloat. But in that case, would we not be better off with an array instead of a scattering of data across the heap?
Perhaps 'struct conflict_info' shouldn't contain a 'struct merged_info' and instead be just the "extra" data. Then we could have a contiguous array of 'struct merged_info' values for most of the paths, but heap pointers for 'struct conflict_info' as necessary.
It's also true that I haven't fully formed a mental model for how these are used in your algorithm, so I'll keep reading.
Show 22 quoted lines
> + path_info->merged.directory_name = current_dir_name;
> + path_info->merged.basename_offset = current_dir_name_len;
> + path_info->merged.clean = !!resolved;
> + if (resolved) {
> + path_info->merged.result.mode = merged_version->mode;
> + oidcpy(&path_info->merged.result.oid, &merged_version->oid);
> + path_info->merged.is_null = !!is_null;
> + } else {
> + int i;
> +
> + for (i = 0; i < 3; i++) {
> + path_info->pathnames[i] = fullpath;
> + path_info->stages[i].mode = names[i].mode;
> + oidcpy(&path_info->stages[i].oid, &names[i].oid);
> + }
> + path_info->filemask = filemask;
> + path_info->dirmask = dirmask;
> + path_info->df_conflict = !!df_conflict;
> + }
> + strmap_put(&opt->priv->paths, fullpath, path_info);
> + result->string = fullpath;
> + result->util = path_info;This is set in all cases, so should we use it everywhere? Naturally, there might be a cost to the extra pointer indirection, so maybe we create a 'struct conflict_info *util' to operate on during this method, but set 'result->util = util' right after allocating so we know how it should behave?
Show 7 quoted lines
> @@ -91,10 +136,12 @@ static int collect_merge_info_callback(int n, > */ > struct merge_options *opt = info->data; > struct merge_options_internal *opti = opt->priv; > - struct conflict_info *ci; > + struct string_list_item pi; /* Path Info */ > + struct conflict_info *ci; /* pi.util when there's a conflict */
...
> + setup_path_info(opt, &pi, dirname, info->pathlen, fullpath, > + names, NULL, 0, df_conflict, filemask, dirmask, 0); > + ci = pi.util;
Here is the use of 'pi' that I was talking about earlier.
Thanks, -Stolee