From: John Goerzen Date: Tue, 26 Feb 2008 14:04:57 GMT Subject: Re: "Contributors never merge" and preserving history Message-ID: In-Reply-To: On 2008-02-25, Linus Torvalds wrote: [ snip ] > So the reason you should generally pull from downstream rather than > upstream is that it keeps your development branch "focused" or "on target" > or whatever you want to call it. And that's always a good idea, because > now anybody who works together with you knows what he is getting. Hi Linus, Thank you very much for these two informative messages. I think that there were a lot of shades of gray to the kernel workflow that I failed to appreciate before, for whatever reason. I do have a question about the point you make above though. I'm not quite understanding what you're saying here. Technically speaking, the end result of a merge where you pulled from me would be identical to a merge where I pulled from you. Moreover, say I'm pretty far down on the seniority list, kernel-wise. Do you expect subsystem maintainers to honor a request from me to pull from my tree, even if they've never heard of me before, or would you think they'd only want git format-patch output? I ask because let's say I follow that advice above, and there are some "downstreams" to me. I pull from them, which involves some merging, and then I want to format-patch. It seems format-patch doesn't work so well with merging. What would I then do in this situation? Should I just use rebase to merge unless I know for sure that upstream will honor a pull request? But then again, we get into trouble if one of my downstreams did a merge. -- John