Stefan Beller [off-list ref] writes:
On Fri, Aug 11, 2017 at 5:39 PM, Junio C Hamano [off-list ref] wrote:
...
quoted
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.
Thanks.
On Mon, Aug 14, 2017 at 12:37 PM, Junio C Hamano [off-list ref] wrote:
Stefan Beller [off-list ref] writes:
quoted
On Fri, Aug 11, 2017 at 5:39 PM, Junio C Hamano [off-list ref] wrote:
...
quoted
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 ;-)
quoted
(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.