On 4/30/16, Steve Schow <st...@bstage.com> wrote: > > what happens if an update VERSION is specified that is not a descendant of > the node we checked out from? What if the VERSION is on a completely > different branch?
Your current check-out and VERSION will have a common ancestor X. Fossil finds all the differences between X and the current check-out, then applies those differences to VERSION. It is possible (though uncommon) to get merge conflicts during this process, which is one reason why there is a "fossil undo" command to back out the update in the rare case where it does not work out well. > > In both merging and updating, there is a possibility for merge conflicts. > update -n will let us check to see if there are some but what is the > automated way to resolve merge conflicts during or just prior to a merge? > The 3 way merge command is probably the way to do it I guess, so I am > assuming the answer to my question is in order to bring a working checkout > up to date with the branch its on, first run update -n, if there are noted > merge conflicts, then use the information to run the 3 way merge tool to > update the working checkout in such a way that running update -n no longer > produces a merge conflict, then finally run update to bring the working > checkout completely up to date with the branch it its on, and work in > progress still retained. Do I have that right? Any suggestions about > automating that process? Fossil runs the 3-way merge automatically. That is what "fossil update" does. There is no extra work to do on your part. Usually it "just works". I cannot remember the last time I hit a conflict while using "fossil update" to flip between branches in SQLite. > > fossil update does an implicit pull before bringing the repo up to date > before bringing the working checkout up to the leaf of the branch its on, > presuming you don’t try some funny business with the VERSION argument, does > fossil checkout also do an implicit pull? > I so rarely use "checkout" that I don't remember :-) Use the source, Luke! -- D. Richard Hipp d...@sqlite.org _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
