[please keep the Cc list] On Sonntag, 29. November 2009, Peter Weseloh wrote: > But on the other hand the intermediate merges from the Mainline make > for much simpler merges, right?. > If merging is done only when Feature_A is ready it might become a real > pain. It might take several month to complete it and the mainline > might have changed a lot. Incidentally, Junio has blogged about this just the other day: http://gitster.livejournal.com/42247.html Basically, as soon as you merge Mainline into Feature_A, you change the topic of Feature_A from "Feature for Release_1.0" to "Feature for this Mainline". Clearly, this topic is not suitable for Release_1.0 anymore. There is a way around this that doesn't sacrifice the topic-oriented nature of the branch: You keep developing Feature_A as planned for Release_1.0 and when you notice that merging this feature to Mainline will become increasingly complex, you fork off a new branch Feature_A_for_Release_2.0 from Mainline and merge Feature_A into this new branch: o--o--o Release_1.0 / \ \ o-o-o--o--o-o-o-o-X-o---o--o Mainline \ \ F1 o--o Feature_A_for_Release_2.0 \ / / F2--------F3-F4 Feature_A The fork point X must be in Release_2.0. -- Hannes -- 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