On Mon, Aug 14, 2017 at 12:37 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Stefan Beller <sbeller@xxxxxxxxxx> writes: > >> On Fri, Aug 11, 2017 at 5:39 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> ... >>> My preference however is to keep sb/diff-color-move topic as-is >>> without replacing and fixing it with incremental updates like these >>> patches. >> >> I would have hoped to not need to reroll that topic. >> Though I do find patches 1&2 valuable either on top or squashed >> into "[PATCH] diff.c: color moved lines differently" and >> "[PATCH] diff.c: color moved lines differently, plain mode" >> respectively. >> >> So I'd ask to pick at least patches 1&2 on top of that series, please? > > Yeah, that is exactly what I did before reading this message but > after reading your comments on the patches ;-) > >> (I am missing the context for *why* you preference is to not do >> exactly this). > > 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: * The patches are written 2 month apart, which may indicate that there was real usage and hence fixes with a more substantiated understanding of the new feature. * We should not strive for "perfect" history IMHO. That is because commit messages provide a lot of reasoning and add a lot of value for understanding the code. If I were to squash and reroll, I would need to make sure these points are addressed in the commit message to have a result that is equally good. The history only needs to be "good-enough", which we defined to "bisectable on all platforms that we care about", fixups/bugfixes are like the cherry on the cake, it draw attention on its own. Not a bad thing IMHO.
