2011/2/7 Lohre, Jan
<jan.lohre@xxxxxxx>
when I have a series
of commits and rebase them, each and every commit gets
individually reapplied. But I will only check the
latest one for correctness and consistency (although I
could of course go through all commits, get them to my
working tree, build and test them). This could lead to
commits that would not even compile.
that's true, this is the inherent priceyou have to pay when
rebasing a patch series as all
commits are rewritten. When doing a merge instead only the
new merge commit has to
be tested (if all the other commits have been already
tested earlier). But, then the
history isn't linear anymore ;-()
Or if I have a commit
introducing a null guard – and on the central git
repository somebody removed the possible null
condition, after a rebase it looks like I have
introduced a null guard where null could never happen.
But it's also possible that a merge creates logical
nonsense as the algorithm operates on plain
text level and doesn't know anything about semantics. So if
you add the null check and then merge
in another change which adds the same null-check three
lines earlier the merge won't raise a conflict
but you would end up with a redundant null-check.