On Thu, Jan 28, 2010 at 4:33 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Mike Linck <mgl@xxxxxxxxxxxxxxxxxxxxxxxx> writes: > >> I understand that there are mechanism kind of available to address >> this problem. If we (all developers in my company) remember always to >> rebase -i before they merge their topic branches back in, then it >> could be squashed making it easier to identify and cherry pick onto >> other branches, or *if* we always remember to rebase before we merge >> and then create a patch set and store that on the topic branch, we >> could kind of organize our change sets that way. > > On the quite contrary, probably an easier way is to pick a the oldest > commit that a fix or enhancement would apply, build a topic that deals > with only the fix or enhancement in question without doing anything else > on top of it, and merge the resulting topic. The choice of the fork point > needs to be made wisely in such a way that the resulting topic would not > cause too much undue conflicts when merged to a modern mainline but old > enough that you _could_ merge the result to any older maintenance branch > if you choose to. > > One implication is that you do _not_ rebase the series to newer codebase > because doing so would make the result unmergeable to older releases even > if you later realize that the fix/enhancement would be suitable to them. > > And if you fork from older commit than tip, you will automatically get a > non-ff merge when you merge it back to the mainline, which would delineate > the history of the side branch from the integration branches rather > nicely. > nice! -- 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