On Mon, 30 Mar 2009, Dave Airlie wrote:
> >
> > - Don't merge upstream code at random points.
> >
> > You should _never_ pull my tree at random points (this was my biggest
> > issue with early git users - many developers would just pull my current
> > random tree-of-the-day into their development trees). It makes your
> > tree just a random mess of random development. Don't do it!
> >
> > And, in fact, preferably you don't pull my tree at ALL, since nothing
> > in my tree should be relevant to the development work _you_ do.
> > Sometimes you have to (in order to solve some particularly nasty
> > dependency issue), but it should be a very rare and special thing, and
> > you should think very hard about it.
>
> The only case I can think off here, is when I send a tree of bug fixes to
> your tree during -rc and I want to make sure the drm-next tree is tested
> with those fixes applied to it.
I would actually prefer that in this case - especially if things merge
cleanly and automatically - you still aim to not merge with me in your
development branch.
But the "test teh merged state" is obviously a real issue, and it happens
at other times than just during the -rc time. In fact, it happens most
commonly long before you even want to send me any pull requests, simply
because the merge window hasn't even opened yet.
So what's the solution? You want to merge for testing, yet I don't want to
see random merges of the day in the development tree when I pull?
I suspect you can already see the solution coming when I put it that way:
the best way is to simply create a test-branch, and do the merge there,
and use _that_ branch for testing and for (for example) sending off to the
linux-next repository which will combine it with yet other test branches.
But note: none of these rules should be absolutely black-and-white.
Nothing in life ever is. Sometimes merging with my tree is simply the best
option. If it's not your normal mode of operation, but an option in your
toolbox that you end up using when everything else is just too painful, go
ahead.
Git does allow people to do many different things, and solve problems
different ways. I just want all the regular workflows to be "good
practice", but then if you have to occasionally break the rules to solve
some odd problem, go ahead and break the rules (and tell people why you
did it that way this time).
> Thanks for all this, its quite clear now, I should clean this mail up and
> put it into the kernel documentation.
Hey, good idea. We have some of that, but if you found the email useful,
do feel free to turn it into real documentation.
Linus
------------------------------------------------------------------------------
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
