I've read the /Addendum to "MaintNotes"/ document¹ several times in the last few years, but in the process of trying to employ the policy with my current team, our progress is stuck on a case that isn't addressed by the policy -- directly, anyway. In the policy section "Handle the remaining patches," the first clause reads as follows: ,----[ First case for remaining patches ] | Anything unobvious that is applicable to 'master' (in other | words, does not depend on anything that is still in 'next' | and not in 'master') is applied to a new topic branch that | is forked from the tip of 'master'. This includes both | enhancements and unobvious fixes to 'master'. `---- It addresses topics that can be built on top of the "master" branch, these topics not depending on anything only available outside the "master" branch, such as in the "next" branch. This policy is focusing on the receiver and integrator of patches, rather than the author, but it's not hard to infer that an author should start his work from the "master" branch in order for his patches to be eligible for treatment by this clause. What about the case where an author started his work from the "next" branch instead? He may have submitted an earlier batch of work that's still cooking in "next," and now he needs to build something else that can take advantage of that earlier work. It's clear that if he starts from "next" and relies on that earlier work, then his later work is not independent and cannot possibly graduate to the "master" branch unless and until his earlier work graduates too. Is the Git policy on such dependency simply, "Don't do that?" Consider a situation where the earlier topic branch's contribution cooking in "next" is looking good and everyone is feeling confident that it's going to graduate, and our poor author /needs/ to get started on his next task that would make use of the earlier work. If he does start his new topic branch from "next" -- or maybe starts it from his earlier topic branch instead -- what will go wrong later? Is there a part of the policy that addresses this case that I missed? Footnotes: ¹ http://www.kernel.org/pub/software/scm/git/docs/v1.7.10.1/howto/maintain-git.txt -- Steven E. Harris -- 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