Rubén Justo <rjusto@xxxxxxxxx> writes: > After re-reading the series today, I still believe the change in the > message for [2/2] or rebasing on 506f457e48, add value to the series, > but I also see that it's not a significant improvement. Besides that > minor detail, IMHO, I think we have consensus on the changes. I think we have established that the "Don't attempt a one-shot export with shell functions---it would not work" is not all that important to stress on *in* *the* *context* *of* *this* *series*. After all, that is why the latest shape of the series is not to do the "keep the already known to be bad commit, followed by a fix-up to illustrate exactly why the first one breaks" pattern, which is designed to help future developers when the breakage is rather subtle and we all miss in our initial reviews, but is rather unusual for a topic that hasn't hit 'next' yet. Instead we just correct our mistakes and pretend as if we just got straight to the right solution. So, let's just use what we already have queued, without details that are irrelevant for the final shape of the history that did not have such a screw-up in the code. The "Don't attempt a one-shot export with shell functions" message, as you said, is already captured in a more relevant place to help developers. We could expand that part in the documentation patch, or even a new documentation patch, but this topic, and especially its test part, is about ensuring that the pager support added here will correctly deals with a stuck pipe, and no developers who hit this commit either by browsing "git log" or by finding it in "git blame" would be seeking an advice on "one-shot export", as that is not a mistake this series _did_ _not_ commit, at least to them.
