On Sat, Apr 07, 2012 at 10:16:28AM +0700, Kriangkrai Soatthiyanont wrote: > It seems that `fossil changes` will show MERGED_WITH when you used > `fossil merge`, not when `fossil update` (to fix "would fork" error). > Anyway, after you have manually resolve conflicts, MERGED_WITH is > still shown, so it seems there is no way to know which files have > conflicts resolved, which files not.
What you tell looks to me like a bug in fossil. If fossil cannot keep the merge information after "fossil update", it should disallow the update. My preference, though, would be it to keep the merge information. > By the way, here is my workaround to mark unresolved merge files: Fossil does not have a good solution to care on merge conflicts beyond notifying the user at the time the conflict just happens. I've also used an approach similar to what you used. In any case, if you have merge conflicts, have not resolved them, and you run "fossil update", this can cripple your files far more. Detecting marked conflicts before commit and specially before any merge (update or merge) would be great. Of course, if you do anything wrong, even committing files with conflicts, it's a VCS and you could repeat the action starting over from the checkins. In your case, Kriangkrai, I'd probably have comitted *forking* (commit -f), and then merge the branches. That would have been the best way to reflect your current merging procedures in the version graph, instead of trying to fix all playing with your checkout. Regards, Lluís. _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
