Hello, I think the thread got a bit derailed because of my fear the "XY problem", which makes me unable to resist detailing my particular instance of the problem when prompted. So I will give a full transcript of the "problem" below, but I'd like to first clarify the whole point of my posting.
As of now, we've got in fossil: (1) "fossil checkout" without flags, which changes the "current commit" pointer and changes the working directory accordingly, bailing out if there are unsaved changes (2) "fossil checkout --force", which changes the "current commit" pointer and changes the working directory accordingly, overwriting unsaved changes (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. I happen to have a situation where (3) or (4) is a useful feature, we can discuss it as you please, but the fact is that the feature exist but I find it a bit inconsistent. 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? I genuinely believe these are worthwhile questions, no matter how I came up with a use for the feature. Can we pretty please address them? As for the situation that posed problem, that I solved with "fossil checkout --keep --force", please keep in mind that it is a rare problem, consequence of a pile-up of several mistakes or things that went wrong. So the direct value of solving this problem is very limited, since my instance is solved and I might not encounter another instance in the next decade. So take this as a purely educational endeavor before deciding whether it is worth your time. To help you understand how I come into such a situation, I'll clarify that while I agree that history should be immutable and not rewritten, I do believe in "writing history", in that I craft my commits carefully to make things best for people who will stumble upon it much later, after a bissect or a blame. 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. on Thursday 06 July 2017 at 15:09, Andy Bradford wrote: > First, will you provide a minimal working transcript of the problem > you're encountering? on Thursday 06 July 2017 at 15:28, Warren Young wrote: > At this point, I want a working test case showing the problem. Please consider the following very-simplified situation: $ fossil init repo.fossil $ mkdir work1 work2 $ cd work1 $ fossil open ../repo.fossil $ seq 10 >data.txt $ fossil add data.txt $ fossil commit -m "New data (1)" $ cd ../work2 $ fossil open ../repo.fossil $ sed -i 's/3/A/;s/9/BC/' data.txt # full feature $ cd ../work1 $ sed -i 's/3/A/;s/9/B/' data.txt $ 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? And please, don't discuss the scenario, yes it's stupid, yes I made several mistakes or dirty things to reach that point, but still, I reached it. We can dismiss it as being clearly beyond normal fossil operations, and I don't ask fossil to make it easy to deal it. I would even find it normal if it was needed to resort to direct SQL manipulation to solve it. It just turns our that "fossil checkout --keep" exists and it raised a question that I think is interesting beyond this stupid single unlikely instance. Example that worked for me: $ fossil checkout --keep --force --latest $ fossil commit -m "The feature" There was some discussion about using "fossil update" instead of the "fossil checkout --keep" above, but produces a merge conflict that has to be dealt with. I hate undoing by hand something a tool did, but it's infrequent enough to deal with it. But for this simplified to work like my situation, you have to imagine that there would be so many merge conflict to be humanly resolved. And what really prompted this whole thread, is that having "checkout" and "--force" in the same command line is very uncomfortable when "fossil checkout --force" (without --keep) would destroy very important data, and I can't fathom why --force is even needed in combination with --keep. Have I left anything unclear? Natasha _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
