Re: Messing with the VC history

[Stephen J. Turnbull]

Lars Brinkhoff writes:
 > Stephen J. Turnbull wrote:
 > > John Yates wrote:

 > >  > Are they under the impression that by contrast a merge absolves
 > >  > them of any need to run tests?
 > >
 > > Of course not!  They know for a fact that they already ran them on
 > > the revisions in their feature branch and on the merged code, and
 > > that the rebased revisions will be *different* from the revisions
 > > they ran tests on.  They object to running the tests *twice* when
 > > once should do.
 > 
 > I've met some of those.  Is there a counterargument?

(I'm not sure what you're asking.  HTH)  It depends on the purpose of
the tests.

- If the purpose of the tests is to ensure that *released* code is
  "clean", then you only need to test the merge version.  No problem,
  rebase and test when you feel like it. :-)

- If the purpose of the tests is to ensure that each revision in the
  DAG is "clean" (eg, in order to make bisect as accurate as
  possible), then it substantially reduces time and annoyance for the
  the developer to test each change in the feature branch then *merge*
  and test the merge commit.  This case basically comes down to a
  vote between the "pretty DAG" folks and the TDD crowd.[1]

- If the purpose of the tests is to ensure that each commit in the DAG
  is "clean" in the context of the latest revision before yours, then
  it makes sense to rebase and test each revision in the rebased
  branch.  You only do as much testing on the feature branch as gives
  you confidence you won't have to do much debugging and repair for
  rebased commits.  In this case there is no conflict between rebasing
  and thorough testing.

Personally, I'm kinda OCD and tend toward Type C most of the time.
(I've also read and understand the git documentation.  You see my
problem, I think. :-)  I find bisect very useful on occasion, so would
rule out Type A if at all possible.  But I find Type B plausible, and
think it's a matter of taste.

Footnotes: 
[1]  However, some people think a mainline with only merge commits on
it is pretty, and they just oppose rebasing on principle.