C99 "for (int ..." form on "master" (was: [PATCH v3 4/5] merge-ort: shuffle the computation and cleanup of potential collisions)
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- Jul 25, 2022, 12:00 UTC
- Message-ID
- <220725.86zggxpfed.gmgdl@evledraar.gmail.com>
- In-Reply-To
- <220701.86o7y9b2ys.gmgdl@evledraar.gmail.com>
On Fri, Jul 01 2022, Ævar Arnfjörð Bjarmason wrote:
Show 20 quoted lines
> On Fri, Jul 01 2022, Elijah Newren via GitGitGadget wrote:
> [...]
>> @@ -3106,6 +3105,7 @@ static int detect_and_process_renames(struct merge_options *opt,
>> {
>> struct diff_queue_struct combined = { 0 };
>> struct rename_info *renames = &opt->priv->renames;
>> + struct strmap collisions[3];
>> int need_dir_renames, s, i, clean = 1;
>> unsigned detection_run = 0;
>>
>> @@ -3155,12 +3155,22 @@ static int detect_and_process_renames(struct merge_options *opt,
>> ALLOC_GROW(combined.queue,
>> renames->pairs[1].nr + renames->pairs[2].nr,
>> combined.alloc);
>> + for (int i = MERGE_SIDE1; i <= MERGE_SIDE2; i++) {
>
> The "int i" here will need to be pre-declared earlier, per: 6563706568b
> (CodingGuidelines: give deadline for "for (int i = 0; ...", 2022-03-30)
>
> I also don't mind us just saying "we've waited enough". Junio?This case got fixed, but per the changed $subject others have snuck through.
Since be733e12001 (Merge branch 'en/merge-tree', 2022-07-14) we've had these forms on "master", see 6debb7527b0 (merge-ort: store messages in a list, not in a single strbuf, 2022-06-18) and cb2607759e2 (merge-ort: store more specific conflict information, 2022-06-18).
We could "fix" those, but per the above I think it's just as valid to just move up the deadline & say that 2.38.0 will have a hard dependency on this C99 feature...