Stefan Beller <sbeller@xxxxxxxxxx> writes: >> I see what I wrote can be misread, especially due to its lack of >> ",instead", that I want to keep the broken one as-is, with neither >> reroll nor fixup. That is not what I meant. >> >> - If you choose to squash so that the resulting history after the >> series graduates to 'master' will be simpler to read (due to lack >> of "oops, that was a mistake"), I do not mind a reroll. >> >> - On the other hand, as the topic has been in 'next' for some time >> and presumably people tried it in their real daily work when >> needed, keeping what is queued as-is has a value---we have a >> fixed reference point that we can go back to to compare the code >> with and without the fix. >> >> I do not have a strong preference, but if I were asked to choose, >> I'd choose the latter. > > We'll go with the latter then. Thanks! > > Other reasons for the latter that I want to add: Yup, we are on the same page. You articulated what I meant in the "On the other hand" bullet point in a better way. Even though we generally do not tolerate stupid mistakes and design errors to clutter the history if they are found early in the review process while the patches are still in flight, code that have been "in" for extended period of time and then found it has room for improvement is a different matter. There is a reason why we thought it was good enough initially, and there is a reason why we later found it needing improvement. Doing the latter as an incremental fix-up is a good way to leave records for both in our history. And to make that kind of incremental refinement useful, it helps to keep the history clean from an initial attempt riddled with trivial issues that are found early in the review is also important.
