[cmake-developers] How to fix a commit to next?
Brad King
brad.king at kitware.com
Tue Aug 31 08:44:23 EDT 2010
On 08/30/2010 10:31 PM, Philip Lowman wrote:
> I read this about 3 hours ago and laughed out loud thinking, ha that
> will never happen to me.
Hah! It happens to everyone. At least now it stays in next until
it has been fixed instead of piling up in "cvs head" ;)
> I was trying to push a change to next that conflicts with a
> previous change I pushed to next.
[snip]
> How do I fix this without waiting for the original push being merged to
> master?
Create a topic to merge the conflicting topics together, say A and B:
...o----o master
. \ \
. \ o----o A
. \ \
. \ o resolve/A/B
. \ / \
. o-----o B \
. \
........o----o next
Then ask the stage to merge 'resolve/A/B' into next. When we later
go to merge to master then we can merge the resolve topic directly
instead of having to re-resolve the conflicts you already handled.
> (FindGTK2_10688 was the original change to next)
> (FindGTK2_11186_gdk_pixbuf when submitted contained changes in
> FindGTK2_10688.
You could just start one topic on top of the other. Even if they
are technically independent I don't think anyone would care about
getting one bug fix but not the other.
> $ git branch "FindGTK2_11186_gdk_pixbuf" 500e630
> fatal: A branch named 'FindGTK2_11186_gdk_pixbuf' already exists.
Git work trees can be in so many states that providing cut-and-paste
instructions that always work is very hard. If you already have
the branch and it already points at 500e630 then just skip this step.
I'm considering removing the instructions from the stage merge failure
message because the above 'resolve/A/B' technique is better anyway.
It explicitly creates a commit to document the conflict between the
two topics, which not only makes a later merge to master easier but
is good to have in history.
-Brad
More information about the cmake-developers
mailing list