Re: [PATCH ps/stash-in-c] strbuf_vinsertf: provide the correct buffer size to vsnprintf

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Feb 6, 2019, 11:41 UTC
Message-ID: <nycvar.QRO.7.76.6.1902061234250.41@tvgsbejvaqbjf.bet>
In-Reply-To: <xmqqzhraru5x.fsf@gitster-ct.c.googlers.com>

Hi Junio,

On Tue, 5 Feb 2019, Junio C Hamano wrote:

Show 17 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> >> 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?

No, I thought I had made my wish clear in the past: to advance ps/stash-in-c to `next` a long time ago, mainly because it became obvious that Paul is too occupied with University things to really pay attention to the discussions on the Git mailing list. Consequently, we cannot really do the regular thing where the branch is cooked in `pu` because the main contributor is not really able to spend the time cooking. So to me, it sounded like the safest way forward (without losing the entire ps/stash-in-c branch) would be to merge it into `next`, with known fixes on top, and cook it from there, with more cooks involved (which I heard some people believe is not a wise thing to do, but then, we do that in Git all the time).

So what I tried to say is that I am a bit opposed to start squashing into Paul's patches, and rather do things on top as the --intent-to-add fixup that I already provided. You seemed to suggest completely otherwise, which got me puzzled.

> 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.

Well, you're the boss of git.git. I find it sad though, personally, that we could not move this forward, especially since we introduced the safety hatch for the very purpose of moving this forward, all the way into the upcoming release.

I would have wished that ps/stash-in-c went into `next` already, what with the few corner case bug fixes we had recently.

Ciao, Dscho