Features Download
From: Linus Torvalds <torvalds <at> linux-foundation.org>
Subject: Re: [git pull] drm-next
Newsgroups: gmane.comp.video.dri.devel
Date: Sunday 29th March 2009 23:59:14 UTC (over 9 years ago)
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
> >    issue with early git users - many developers would just pull my
> >    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
> >    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,
> >    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 

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.


CD: 3ms