On 8/11/15, arnoldemu <[email protected]> wrote: >>That's a painful way to do it. Unless you have conflicts, merging should >> be >>painless. It sounds to me like you are using 'fossil gdiff' to resolve >> your >>merges manually instead of using 'fossil merge'? > This was only a work around because I couldn't use meld to resolve my > merge. > > I do always use fossil gdiff before I commit after a merge to double check > the results. > > If I can't use meld, can anyone suggest a merge tool which shows it's > differences like meld/p4merge do, and allow me to edit and works with > fossil's gmerge-command as it currently stands? >
Can you provide a more detailed description of your workflow? I don't really understand your problem, but I would like to. I think if you explain it in more detail I might be able to catch on. I've never used a "merge tool". Usually when we do merges in Fossil or in SQLite, there are no conflicts. We just type "fossil merge BRANCH" and everything works. Rarely, a conflict will show up, in which case fossil just leaves marks in the source file: <<<<<<< BEGIN MERGE CONFLICT: local copy shown first <<<<<<<<<<<<<<< ======= COMMON ANCESTOR content follows ============================ ======= MERGED IN content follows ================================== >>>>>>> END MERGE CONFLICT >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So then I use an ordinary text editor to go in and sort out the conflict. I'm trying to understand what it is that you are doing that makes the procedure above impractical. Are you somehow getting an avalanche of merge conflicts? What's going on to make you think you need a "merge tool"? -- D. Richard Hipp [email protected] _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
