Junio C Hamano <gitster@xxxxxxxxx> writes: > But at least I view it as a step that needs to happen sometime > between now and at the end. I do not yet have an opinion on > which one is more pleasant, between (1) having to deal with a > single Makefile that needs to be aware of two different locations > *.[ch] lives in, and (2) having to deal with two Makefiles that > duplicates definitions and risks them needlessly diverging. FWIW, I am leaning towards the latter, with the assumption that this may take more than a cycle to cook in contrib/. Adding the Makefile bits to the top-level and keeping the topic in 'next' means all the topics that pass the pipeline will need to be written in such a way that its Makefile change works well with and without the unified Makefile bits from this topic, an additional burden on other topics this topic would impose. So it is understandable to want to keep the changes to the top-level Makefile to the minimum, even if it may mean that it requires more effort in the end to clean things up when the topic graduates. An alternative would be to bypass the contrib/ phase and start as a new subcommand that is first-class citizen from day one and let it spend as much time as it needs to mature. It would burden the topics that pass the pipeline while this is cooking the same way as having a unified build procedure in the top-level Makefile, of course, though.
