Re: What's cooking in git.git (Dec 2015, #03; Thu, 10)

Stefan Beller [off-list ref] writes:

On Thu, Dec 10, 2015 at 3:51 PM, Junio C Hamano [off-list ref] wrote:

quoted

Stefan Beller [off-list ref] writes:

quoted

quoted

* sb/submodule-parallel-fetch (2015-11-24) 17 commits
...

I assume you plan on merging this after 2.7 settled and then we can
also get the above sb/submodule-parallel-update going again.

Yeah, thanks for reminding me.  I think that would be a good plan
that gives us an opportunity to clean up this topic, some parts of
which are have "an early patch that was too hastily merged to 'next'
had to be tweaked by an 'oops' follow-up patch in the topic"
pattern, e.g. "make waitpid the secondary and closed pipe the
primary way to monitor children".

Thanks.

This makes it sound as if you would drop it from next once 2.7 is out,
expecting a complete reroll, which does the right thing from the beginning?

Yes, what is still in 'next' when a new release is made has the
chance to (re)do the right thing from the beginning, and it also can
lose merges from other topics in the middle of the topic if they
have graduated to 'master'.

A topic that did the right thing from this cycle already, but needs
to stay in 'next' only because the area it touches is so important
and deserves more real world testing by those who run 'next', may
not have to reroll.

I think two sb/submodule-parallel-* topics fall into the former
category, i.e. ones that can take advantage of the chance to escape
the rigidity of 'next' at the release cycle boundary, and I think
we should grab that opportunity to clean these series up.

Thanks.