On 2009-02-01, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Sitaram Chamarty <sitaramc@xxxxxxxxx> writes: > >> Reversing A and B is one thing, applying a sequence of >> merges in a different order is quite something else. > > This point is true in theory but I haven't found it to cause problems in > practice. Textual conflicts between topics do happen, but it does not > happen so often in overlapping areas across more than two topics that > earlier resolutions to them cannot be reused by the rerere mechanism. [snip] > to force a merge order to the mainline can be used not only to deal with > semantic conflicts but textual ones, too. If two branches textually > interact badly, you prepare a consolidated topic between the two, so that > you can merge A alone, B alone, or A+B together to the mainline. > > If you end up merging A first and then want to merge B later (or the other > way around, merge B and then A), and if the second merge to the mainline > causes huge textual conflicts, you can instead merge the conslidated topic > A+B to the mainline. Thanks; great explanation. I notice you blogged it too, and similar to the "Never merging back" post, the message is: if something is (or is likely to be) an independent feature, it should have its own branch and be merged into others as soon as it is known they need it. (In that post, it was a random crazy feature that one might normally dump into a customer branch, here it's a bugfix B that you might naively dump into feature A, but the basic logic is the same) -- 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
