On Wed, Aug 12, 2015 at 12:35 PM, Linus Torvalds
<torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> Generally, the preferred model is:
>
> - strive to base your development on a well-characterized base (for
> example, a previous release), and _stay_ on that base (ie don't get
> distracted by what other unrelated development projects are doing).
>
> - do *not* rebase of pull from upstream (Dave or me), particularly
> durign the merge window, since all you are doing is just bringing in
> development work that is entirely irrelevant to _your_ development
> work, and potential instabilities from other sources.
Just to clarify: in many ways, rebasing and "back merges" (ie
downstream developers pulling from upstream) are almost
indistinguishable wrt the downsides. Both bring random upstream
development into a downstream project. Both should be done very
carefully, and there should always be a very clear _reason_ for why a
rebase or back-merge is done and why that particular upstream point
was rebased upon or back-merged (and in the case of a back-merge,
please _document_ that reason in the merge message itself).
Back-merges have their own set of problems - they can make the history
much harder to read, and having multiple merge bases can result in
interesting effects (like making the diff statistics for "git
request-pull" be garbage). Of course, rebasing - while generally
keeping the history cleaner - has its own problems too, and makes it
hard or impossible for people to work together if you have some shared
development. So rebasing and back merging are very different, but at
the same time they do share some of the same problems, and generally
it's better the less of either that a development tree needs.
Linus
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
