Workflows, rebase, patch theory

[Ben Finney]

(Please preserve attribution lines on quoted material when replying,
so that we can see who wrote what in your reply.)

Talden <talden at gmail.com> writes:

> >  > AIUI, git users tend to use this to keep their changes up to
> >  > date and "ready for submission" with respect to a trunk. The
> >  > advantage is you don't have commits like "Merge bzr.dev"
> >  > interspersed with your own changes.
> >
> >  Okay. This does seem to be a main complaint against Bazaar and
> >  Mercurial by Git or Darcs users. I don't understand why it's
> >  desirable to hide merges in the history, especially against...
> 
> Well I guess because in a longish running branch that has high
> dependencies with other branches landing in the upstream you can get
> a lot of merge-noise.

I don't see how "information about what happened when" is "noise",
especially in a system that's designed to preserve exactly that
information — which is what a VCS is designed to do.

> In an ideal world all tasks would involve a handful of commits over
> a day or two and not require these upstream merges... Not all
> projects fit this model.

Perhaps. So, in non-ideal cases, it seems folly to throw away
historical information about what actually happened, even if it's less
than ideal.

-- 
 \       “As far as the laws of mathematics refer to reality, they are |
  `\    not certain, and as far as they are certain, they do not refer |
_o__)                              to reality.” —Albert Einstein, 1983 |
Ben Finney