[Bf-committers] Advice on fixing bad merges (Shaders GSoC)

[Alberto Torres]

I don't have experience in such big merges but... wouldn't be easier
to do a diff between the original trunk revision which originated the
branch and the branch, and then apply the diff to a new branch? Or it
would generate too many rejects?



2010/8/1 Jason Wilkins <jason.a.wilkins at gmail.com>:
> I had this problem earlier in the summer.
>
> What we did first was create a giant diff between the trunk and my branch.
>
> What I did then was go through with a copy of trunk and a copy of my branch
> file by file.  If I knew for sure I had not modified a file I copied the
> exact file from trunk over the outdated one hanging around in my branch.
>
> If it was a file that I had modified then I carefully looked at it to make
> sure that the only changes were my changes.  In that case I could simply
> keep my file, otherwise I had to update my file so that the parts I did not
> change myself matched the trunk.
>
> Finally, I did another diff between the newly committed branch and the same
> version of the trunk I started with (this will take long enough its bound to
> be updated while you are fixing this, so make a note).
> This new diff should only contain your changes and if so, you are done.
>
> In other words, I fixed it manually.  It was time consuming but now I'm much
> more careful about making sure my merges are correct :)
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>