Re: Questions about branches in git

Mike Linck [off-list ref] 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.

On Thu, Jan 28, 2010 at 4:33 PM, Junio C Hamano [off-list ref] wrote:

Mike Linck [off-list ref] writes:

quoted

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!