Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> Or that they are read with a fine toothed comb, but that the focus lies
> more on style and maintainability than correctness. We talked about this
> in the past.
Perhaps we can do better the next time, then. I find unreadable
code is impossible to reason about its correctness, so you'd need
to pay attention to style and maintenance issues to quickly get past
that step.
>> Thanks for finding it. This needs to be squashed into bfc3fe33
>> ("strbuf.c: add `strbuf_insertf()` and `strbuf_vinsertf()`",
>> 2018-12-20)?
>
> Since you want to open that can of worms again, you will also want to
> squash ed5d77f7d382 (stash: fix segmentation fault when files were added with
> intent, 2019-01-18) into 1f5a011d90ec (stash: convert create to builtin,
> 2018-12-20). It will have trivial merge conflicts, and the addition of the
> regression test will be surprising without modifying the commit message to
> explain that there was a regression that was fixed very late in the
> development, and that that regression test intends to guarantee that it
> won't need to be fixed again.
Are you saying that I should not merge the series as is but expect
an update that does these squashing? I was planning to make this a
merge-down day, but let me exclude this topic from the "for next"
batch just in case for today.
Thanks.
