> It matters to us end-testers when we do a git bisect. If you leave the
The whole point of the exercise of cleaning up/rewriting the history is to make
the tree as bisectable as possible.
Otherwise e.g. if I submitted patch + fixup + fixup + revert + fixup etc.
everyone doing a bisect would go crazy or rather hit many points
with various subtle breakages.
and let the merging happen at Linus' end (or, at least
Why would you care about the merge and not about the individual patches?
Note that these quilt merges don't have conflicts.
The patches are as tested individually as they were before. I don't see
how you can call something that was in linux-next for some time and also
in my test tree "untested". The completely merged tree is not tested
well [1] in both cases (unless after some time of course) as far as I can see,
no difference.
[1] I do some basic testing as in building and test booting on a few
machines on each merge, so calling it completely untested is not
true.
So when I do a rebase versus Linus doing a merge (end result
the same code base) how is that more untested?
Your point is
Sorry I still don't see the difference. AFAIK the only difference
is that I do the merge vs Linus doing it and that it looks slightly
different in the history, but apart from that (as in what
actually ends up in the source tree) it's all the same.
-Andi
--
