[PATCH 16/17] merge-ort: process_renames() now needs more defensiveness
- From
Elijah Newren <newren@gmail.com>
- Date
- Jan 4, 2021, 23:50 UTC
- Message-ID
- <20210104235006.2867404-17-newren@gmail.com>
- In-Reply-To
- <20210104235006.2867404-1-newren@gmail.com>
Since directory rename detection adds new paths to opt->priv->paths and removes old ones, process_renames() needs to now check whether pair->one->path actually exists in opt->priv->paths instead of just assuming it does.
Signed-off-by: Elijah Newren <newren@gmail.com> --- merge-ort.c | 26 +++++++++++++++++++++----- 1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/merge-ort.c b/merge-ort.c index 115ff6d2d5..480f212cff 100644 --- a/merge-ort.c +++ b/merge-ort.c @@ -1829,12 +1829,28 @@ static int process_renames(struct merge_options *opt, const char *rename_branch = NULL, *delete_branch = NULL; old_ent = strmap_get_entry(&opt->priv->paths, pair->one->path); - oldpath = old_ent->key; - oldinfo = old_ent->value; - new_ent = strmap_get_entry(&opt->priv->paths, pair->two->path); - newpath = new_ent->key; - newinfo = new_ent->value; + if (old_ent) { + oldpath = old_ent->key; + oldinfo = old_ent->value; + } + newpath = pair->two->path; + if (new_ent) { + newpath = new_ent->key; + newinfo = new_ent->value; + } + + /* + * If pair->one->path isn't in opt->priv->paths, that means + * that either directory rename detection removed that + * path, or a parent directory of oldpath was resolved and + * we don't even need the rename; in either case, we can + * skip it. If oldinfo->merged.clean, then the other side + * of history had no changes to oldpath and we don't need + * the rename and can skip it. + */ + if (!oldinfo || oldinfo->merged.clean) + continue; /* * diff_filepairs have copies of pathnames, thus we have to
-- 2.29.1.106.g3ff750dc32.dirty