>
> The common ancestor of v2.4_branch and master is now Y, not X, so git
> only considers changes from Y to Z at the next merge, so the problematic
> commit A isn't in the list. (git determines this automatically
I had hoped it was smart like that ! great
>
> > Truthfully I don't understand
On Sun, Feb 21, 2010 at 08:44:05PM +, Chris Morley wrote:
>
>
>
> > One answer that comes to mind is to remember this, and on the master
> > branch revert the commit after the merge that introduces it.
> >
> > X--o--A--o--o [v2.4_branch]
> > \\
> > o--o--o--M--A' [mas
> One answer that comes to mind is to remember this, and on the master
> branch revert the commit after the merge that introduces it.
>
> X--o--A--o--o [v2.4_branch]
> \\
> o--o--o--M--A' [master]
>
> X represents the place where we branched 2.4, A represents the change
That's a good question, and I don't immediately have the right answer.
One answer that comes to mind is to remember this, and on the master
branch revert the commit after the merge that introduces it.
X--o--A--o--o [v2.4_branch]
\\
o--o--o--M--A' [master]
X represents the
You may find stgit useful.
Regards,
Alex.
Chris Morley пишет:
>
> > At this point we may want to investigate some of the workflows suggested
> > in the gitworkflows[1] document. Specifically, here's how we can use
> > topic branches, integration branches and merging upwards to put safe new
> > fe
> At this point we may want to investigate some of the workflows suggested
> in the gitworkflows[1] document. Specifically, here's how we can use
> topic branches, integration branches and merging upwards to put safe new
> features in 2.4.x after they're proven on master:
>
pncconf in 2.4 will
