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. -- 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