On 10/8/2020 8:50 AM, Derrick Stolee wrote:
> On 10/8/2020 8:06 AM, Jeff King wrote:
>> But regardless, it seems unfriendly that we can't
>> get out of it while merging the graphs. Doing this obviously makes the
>> problem go away:
>>
>> diff --git a/commit-graph.c b/commit-graph.c
>> index cb042bdba8..ae1f94ccc4 100644
>> --- a/commit-graph.c
>> +++ b/commit-graph.c
>> @@ -2023,8 +2023,11 @@ static void sort_and_scan_merged_commits(struct write_commit_graph_context *ctx)
>>
>> if (i && oideq(&ctx->commits.list[i - 1]->object.oid,
>> &ctx->commits.list[i]->object.oid)) {
>> - die(_("unexpected duplicate commit id %s"),
>> - oid_to_hex(&ctx->commits.list[i]->object.oid));
>> + /*
>> + * quietly ignore duplicates; these could come from
>> + * incremental graph files mentioning the same commit.
>> + */
>> + continue;
>> } else {
>> unsigned int num_parents;
>>
>>
>> but it's not clear to me if that's papering over another bug, or
>> gracefully handling a situation that we ought to be.
>
> I think this is a good thing to do, at minimum. As I discussed above,
> the "input data" of the incremental commit-graph chain with duplicate
> commits across layers isn't actually _invalid_. It's unexpected based
> on what Git "should" be doing.
As I was working on my own version of this, I realized that just
commenting here still creates duplicate commits in the new layer,
which is even MORE unexpected. It could cause some confusion with
the binary search, but likely that is still fine. The only "real"
issue is that it is wasted data.
I'll send [1] to the list soon (after build & test validation),
but it includes copying the pointers to a new "de-duplicated" list.
[1] https://github.com/gitgitgadget/git/pull/747
Thanks,
-Stolee
