Using Bitbucket, when I try to sync my ML fork with the master I'm getting the error message "Unable to merge - conflicts during merge". Problem is: even after resolving all issues with files marked with "conflict" in the diff, it still fails w/o any file marked as a problem - unlike the promised "View the conflicts".
I have encountered this problem multiple times by now and the only solution I found is to completely reset, i.e. delete the repo, re-fork and re-patch in all my changes. Is there any way to find out what the problem is - probably by running hg directly w/o BitBucket? Thanks!
If I get conflicts, I would try to do the merge locally, rather than via Bitbucket.
You will get a 3-way merge dialog and you choose manually what changes to merge and what not. But it's quite easy to screw it up (e.g. for 5D3 123 I'm tempted to export all patches, start a fresh branch, and re-apply them).
Nanomad and g3gg0 are experimenting with patch queues. For local changes, I use "hg pull --rebase", or manual patches.
This is the reason I don't ever commit to unified in my own repo. Always commit your own changes to a branch. You won't ever need to make new forks if you keep unified 'clean'. And you can even submit more than one pull request at the same time from a single repo.
Whenever I get merge conflict I usually just edit the files manually b/c often 'use theirs' and 'use mine' are wrong, the 'correct' merge is actually some combination. Just search for '<<<<<<<' in the files and fix them all.
http://www.magiclantern.fm/forum/index.php?topic=9524.0
These are great tips (just made them sticky).
Quote from: dmilligan on February 15, 2014, 04:53:53 PMAnd you can even submit more than one pull request at the same time from a single repo.
Thanks for this information because making a new repo fork for every trivial pull request as I used to do is a major pita :-o and doesn't really motivate to submit small changes.
Clutters the commit log a little, but usability looks significantly better.