Hi Junio,
On Tue, 5 Feb 2019, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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
