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 _______________________________________________ cmake-developers mailing list cmake-developers@cmake.org http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers