On 2008-02-25, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> 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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
