Junio C Hamano wrote: > I take it to mean that even though v[345] have diverged, the area that the > particular change you have in mind has to touch haven't changed since they > forked. Correct. Sometimes, there might be unrelated changes to a given file or files, in which case conflict resolution will be done manually. But generally speaking, bugfixes will tend to go on quite cleanly. > Instead, you can fork such a topic from the latest common. > > o--o--o--o--o--o--o--o v4 > / > --o--x--x--x--x--x--x--x v3 > \ > Y---Y > your change(s) > > and merging this to v3 and v4 will have the desired effect. > > o--o--o--o--o--o--o--o---------M v4 > / / > --o--x--x--x--x--x--x--x---M v3 / > \ / / > Y---Y----------------.-----. > your change(s) > > The merges will incorporate this particular change alone without dragging > anything else. When you merge it to v4, none of the unrelated 'x' will be > merged into it. That sounds a whole lot like what I need. Right now I'm thinking that the right approach is that once we have released v3, and started working on v4 heavily, we will probably not want to check any commits directly into v3. Bugfixes will have their own branch. If there is a whole new project or whatever being done on top of v3, it will have its own branch as well. So once v3 is in beta or whatever and we declare a code freeze, we could have a rule that all commits must be merge-commits coming from dedicated branches with descriptive, intelligible names. For each dedicated branch, some thought will have to be given as to just where off of v3 to branch it from (not just carelessly off the latest tip). Meanwhile, new development will continue on v4, with lots of commits going right into the branch (or into v4 sub-branches with occasional merge-commits into v4). -- 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