On Mon, Apr 11, 2011 at 7:54 PM, Alaric Snell-Pym <ala...@snell-pym.org.uk>wrote:
> ...worked, but complained that there was no common ancestor for the file > added in the cherry-picked commit. I didn't have time to try it with > actual content that gets merged, but I'm hoping the system realises it's > got some changes already present due to cherry-picking and doesn't > explode about conflicts if so... > FYI... i haven't verified this with more than one merge and subsequent merge-back (cherrypicked from trunk to a branch, the eventually merged back into the trunk), but i just got a curious merge conflict which was possibly caused by my use case: <<<<<<< BEGIN MERGE CONFLICT: original content first <<<<<<< ... code snipped ... ======= original content above; conflict below ============= >>>>>>> END MERGE CONFLICT: conflict last >>>>>>>>>>>>>>>>>> The second conflict block is empty. i saw same behaviour once before over the weekend, i am fairly certain it was the exact same case described above (possibly even the exact same code block, if memory serves me well (but it doesn't always do that)), but i haven't verified that this always happens. Since i had, before trying --cherrypick, no real expectations of how it would/should/might handle "merge-backs", i can't say that i consider this behaviour to be a bug. Having an empty second block makes the conflict resolution trivial - simply remove the 3 lines generated by fossil. -- ----- stephan beal http://wanderinghorse.net/home/stephan/
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
