Thus said Natacha Port? on Fri, 07 Jul 2017 09:43:56 -0000: > (3) "fossil checkout --keep", which is advertised as changing the > "current commit" pointer without touching the working directory, but > bails out of there are unsaved changes. > (4) "fossil checkout --keep --froce", which changes the "current commit" > pointer whithout touching the working directory and accepts to do so > when there are unsaved changes.
One must keep in mind that both (3) and (4) will not attempt to merge any changes that you have made to managed files. This means that if you have made significant changes to files that are not the same between the current checkout and the new desired target checkout, then you will end up with a huge diff to figure out. In any event, nothing has been lost. If you discover that you don't like the state of affairs, you can return to where you were by doing fossil checkout --keep --force <old-checkout> Again, Fossil will not alter any files at all, but it will show you that there are differences between the version that you are at if there have been edits made to files. > Since "fossil checkout --keep" is not supposed to change the working > checkout, is it rightfully considered dangerous as "fossil checkout" > without flag? Or should the code be updated to have "fossil checkout > --keep" not fail out when there are unsaved changes? Are you suggesting that --keep should imply --force because --keep is non-destructive? Whereas, on the other hand, ``fossil checkout --force'' can be destructive? > So I keep my commit as small as possible while still being a > semantically self-contained unit, so a typical feature spans several > commits. So when developing a feature, I often end up with a working > directory containing changes that are actually a composition of > several future commits. I think keeping your commits as small as possible is fine, however, are those potential future commits a mixed bag of features? If so, why are you also not developing those features in different branches? Perhaps even utilizing multiple checkouts spread over different directories? While Git makes you clone multiple times if you want multiple working checkout directories, Fossil does not, and it makes for a nice workflow if you start taking advantage of multiple open checkouts. > Please consider the following very-simplified situation: > ... > $ fossil commit -m "Helper for the feature" > $ cd ../work2 > $ fossil whatever is needed to make a commit that replaces B with BC > > What is the whatever here? So you've made changes to data.txt in one commit in a different checkout and now in the work2 checkout you have additional, uncommitted, changes that potentially conflict? As you can see: $ fossil commit -m whatever would fork. "update" first or use --allow-fork. So, Fossil knows there are additional changes that haven't yet been merged into your work2 checkout. What you do at this point is your choice. (1) one choice is to commit the change (as I suggested in a different email) using --allow-fork and defer the decision of resolving a merge until later. (2) another choice would be to commit the change to a branch using ``fossil commit --branch newwork'' and again defer the merge until later. (3) you can run ``fossil update'' which might result in a clean merge, or it might result in conflicts to be resolved. If you don't like the conflicts you can bail out using ``fossil undo'' as Richard suggested. Here's 3: $ fossil up MERGE data.txt ***** 1 merge conflicts in data.txt ------------------------------------------------------------------------------- updated-to: 2857ae3ebc14c271613d2e43207f3145daaaf3c8 2017-07-08 03:52:00 UTC tags: trunk comment: Helper for the feature (user: amb) changes: 1 file modified. WARNING: 1 merge conflicts "fossil undo" is available to undo changes to the working checkout. Yep, there's a conflict. Now what? Well, undo if you don't like it, or begin fixing the conflicts. Open data.txt and you'll see this: <<<<<<< BEGIN MERGE CONFLICT: local copy shown first <<<<<<<<<<<<<<< BC ======= COMMON ANCESTOR content follows ============================ 9 ======= MERGED IN content follows ================================== B >>>>>>> END MERGE CONFLICT >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> You said you wanted BC, so remove all lines except the line that says BC. Then commit that change and you have resolved the conflict. But, if you don't like that approach, and instead decide to undo, then you can try to use ``fossil checkout'' as you suggested, but then find that Fossil wants either --keep or --force because there are local changes. You want to preserve them, so you use --keep: $ fossil checkout --keep 2857ae3ebc there are unsaved changes in the current checkout You decide to use --keep and --force together, to switch to the checkout where you added the Helper feature: $ fossil checkout --force --keep 2857ae3ebc $ fossil status repository: /tmp/work2/../repo.fossil local-root: /tmp/work2/ config-db: /home/amb/.fossil checkout: 2857ae3ebc14c271613d2e43207f3145daaaf3c8 2017-07-08 03:52:00 UTC parent: e7eaaad4085a702e6c4b89f171bb7b75d7b671f9 2017-07-08 03:51:07 UTC tags: trunk comment: Helper for the feature (user: amb) EDITED data.txt Ok, so now they are ``merged'' right? Wrong, no merging has actually happened, you just got lucky that the changes are small enough. But Fossil doesn't care, you told it to switch the commit pointer. You now run ``fossil diff'' and things look better: $ fossil diff Index: data.txt ================================================================== --- data.txt +++ data.txt @@ -4,7 +4,7 @@ 4 5 6 7 8 -B +BC 10 And now you're ready to commit, right? $ fossil commit -m whatever would fork. "update" first or use --allow-fork. Wait, what happened there? Unbeknownst to you, someone working in a checkout named work3 has made another commit against the same point in the timeline that you want to commit to (yes, I altered your steps without telling you because in a DVCS this is possible). So now you're faced with other problems. Let's see what happens next: $ fossil commit -m whatever --allow-fork New_Version: e719cd9eb7e46034fe7eac1dc688c4c87e1355a4 **** warning: a fork has occurred ***** Fortunately, and hopefully, this is as simple as: $ fossil merge Merging fork [7dd4f281ca] at 2017-07-08 04:06:28 by amb: "oops" MERGE data.txt "fossil undo" is available to undo changes to the working checkout. Hurray, no conflicts, so we're almost done: $ fossil commit -m done New_Version: c4b827963dd6caf57a49ce5815d84990efa16a97 Thanks, Andy -- TAI64 timestamp: 4000000059605c58 _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
