Shawn Pearce <spearce@xxxxxxxxxxx> writes: >> Except some minor nits, yes. >> >> * I would have preferred two patches, one for "master" and one >> for the C merge-recursive topic (or at least "next"). > > Doh. I didn't realize this was something you were interested in > pulling into master. Applying them directly to "master" does not have much to do with this. Of course, if something is obviously the right thing to do, then I often apply them straight to "master" (or apply them to "maint" and pull the result into "master"). In other cases, I prefer to fork off a new series from the tip of the "master" into a new topic branch. Then merge that into either "pu" (if I have suspicion that it is not ready for even testing yet) or "next", and cook there for a while until it is ready. While being cooked in "next", what happens is that changes to that specific topic are applied to the tip of the topic branch, and then pulled into "next", over and over. Many topic branches are cooked simultaneously that way. So the development history of "next" is, eh, messy. I usually test "next", in other words, multiple topics cooking together. But when some changes are applied to "master" that might interfere with an older but still not in "master", I pull "master" into the topic and test that topic alone in isolation. That way, when a topic matures, we can be reasonably sure that it can be pulled into "master" without breaking things. A single patch on top of "next" depends on all existing topics that may or may not turn out to be useful. That makes such a patch less useful than otherwise be. So if a series affects things in "master" and some other things still not in "master", a preferred way, from my workflow point of view, is to have at least two patches: one for "master" and another for the rest. Then what I would do is to fork one topic off from "master" and apply the former, pull that into "next" and cook that. That part of the topic can graduate to "master" without waiting for other topics in "next". What happens to the rest is a bit more involved. In the case of the hashcpy() patch, one thing that only exists in "next" was merge-recursive.c, but the story would be the same if "next" had more places that used memcpy(a, b, 20) than "master" in a file that are common in two branches. Ideally, the remainder will be broken into pieces and applied as a fixup on top of existing topics (in this case, C merge-recursive topic) and then merged into "next". This can be either done by applying the remainder directly on top of the affected topic, or forking a subtopic off of the affected topic (the latter is useful if the new series might turn out to be dud -- the original topic will not be contaminated by bad changes and can graduate to "master" more easily). In any case, I've done a split myself and the parts that can be applied to "master" is now sitting in gl/cleanup topic and the remainder is sitting in gl/cleanup-next topic which was forked off from C merge-recursive topic (you can tell where their tips are by looking at "gitk next" output) and both are merged into "next". - 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