Messages in this thread | | | Date | Tue, 2 Nov 2021 06:22:55 +0100 | From | Borislav Petkov <> | Subject | Re: [GIT PULL (not really)] x86/core for v5.16 |
| |
On Mon, Nov 01, 2021 at 02:16:24PM -0700, Linus Torvalds wrote: > So other developers do this kind of thing fairly regularly, because > they have some "core branch" that does the basic core development > (say, a driver subsystem), and then they have other branches (eg the > lowlevel drivers themselves etc) that depended on the core work but > are sent as individual pull requests to keep the conceptual separation > alive, and make it easier to review.
Right, exactly.
> The way to do it tends to be: > > (a) make it clear that some pull request depends on a previous one, > so that I'm aware of it, and don't do them out of order and get > confused
Ok.
> (b) when you have a series of pull requests that aren't independent, > create the series of pulls yourself in a temporary tree, and generate > the pull request from that series, with the previous merge always as > the "base".
Ah ok, that sounds good.
> The reason for (a) is obvious, and the reason for (b) is that then > each pull request automatically gets the right shortlog and diffstat. > > Of course, if this is the only time you expect to haev this kind of > dependency, you don't need to have much of a process in place, and a > hacky manual one-time thing like the above works fine too.
Yeah, it does happen but not too often. With tip, the usual situation is one branch does change/add something which is needed elsewhere and a merge is needed. Basically the case you described above.
> And in general, the more independent the pull request can be, the > better. But having two or more branches that have some serial > dependency certainly isn't unheard of or wrong either. It happens.
Yeah.
Ok, thanks for explaining.
/me writes this down for the future.
-- Regards/Gruss, Boris.
SUSE Software Solutions Germany GmbH, GF: Ivo Totev, HRB 36809, AG Nürnberg
| |