Derrick Stolee wrote: > On 7/29/2020 6:19 PM, Jonathan Nieder wrote: > > Derrick Stolee wrote: >>> --- /dev/null >>> +++ b/Documentation/git-maintenance.txt >>> @@ -0,0 +1,57 @@ >> [...] >>> +SUBCOMMANDS >>> +----------- >>> + >>> +run:: >>> + Run one or more maintenance tasks. >> >> [jrnieder] How do I supply the tasks on the command line? Are they >> parameters to this subcommand? If so, it could make sense for this to >> say something like >> >> run <task>...:: > > Hopefully this is documented to your satisfaction when the ability > to customize the tasks is implemented. I think my last reply to this part missed the point a little, so let me try again. In multi-patch series, requests to make improvements to early parts that would be obsoleted by later parts may seem strange --- isn't this just wasted work? Sure, occasionally someone will stumble on the early part using "git bisect" or "git log", but isn't that rare enough to not be worth worrying too much about? And I'd agree with that reaction --- for a documentation nit like this one, that benefit alone is probably not enough to be worth the fuss of tweaking things. When I focus more on early parts of a series, it is for a different reason: from a release management point of view, it is useful to get the early part of a series "cooked" as soon as possible so it can be exposed to users in "next" and then become a foundation for later patches in "master". So we try to get as much of the early part of a series into that state as we can, and to merge the early part even without the later part as soon as the former is ready and valuable enough to users on its own. Relatedly, ensuring each commit is "complete" in this sense on its own gives us more flexibility in case a problem is discovered later: we can revert a patch that is causing issues without having to revert the preceding part. I think that might be part of the context I didn't convey well, and why I want to get this in tip-top shape and start using it. Thanks, Jonathan
