[fossil-users] warning about unsaved changes with `fossil checkout --keep`

[Natacha Porté]

Hello,

I was recently in a very uncomfortable situation, with precious
uncommitted data in the current checkout and the need to change where
the checkout "current commit" points to.

As far as I can tell, that's exactly what `fossil checkout --keep` is
for, but my attempts were met with the message "there are unsaved
changes in the current checkout" and an error status code.

Is it really needed?

I hate dealing with precious data, even with backups and all sorts of
safety nets, because nothing is ever 100% reliable. So this error
message caused me a significant cognitive load, to triple-check that
everything was as I thought it was and that --forcing the command would
indeed do what I thought it would do.

Now I'm obviously biased by this experience, and that might make be
blind to a good reason to keep the current behavior. So I'm just humbly
asking whether we should keep the `fossil_fatal` for unsaved changes
when --keep flag is given.

Also, while looking at the code, I had the feeling that there is
unconditional disk-touching stuff that should be skipped with --keep,
but that's probably more debatable than the bias in the heat of the
moment made me think.


Natasha

[Richard Hipp]

Post by Natacha Porté
Hello,
I was recently in a very uncomfortable situation, with precious
uncommitted data in the current checkout and the need to change where
the checkout "current commit" points to.

That's what the "fossil update" command is for.

If you are current only checkin "a1234" and you have made edits, but
then you decide you want those edits to be applied to a different
checkin "b2345", you type:

fossil up b2345

Fossil with then move the current checkout to b2345 and attempt to
merge all of your edits into that checkout. This might result in
merge conflicts. If so, and if you do not like what happens, you can
also do "fossil undo" to restore your state to exactly what it was
before you did the "fossil up".

If your edits are truly precious and you are concerned about losing
them, you can also run:

fossil stash snapshot

To make a snapshot of your edits. Then if something goes wrong, you
can always return to them later.

I do not remember what "fossil co --keep" is for. I'm sure it has
some purpose. But moving the current check-out is not that purpose.

Post by Natacha Porté
As far as I can tell, that's exactly what `fossil checkout --keep` is
for, but my attempts were met with the message "there are unsaved
changes in the current checkout" and an error status code.
Is it really needed?
I hate dealing with precious data, even with backups and all sorts of
safety nets, because nothing is ever 100% reliable. So this error
message caused me a significant cognitive load, to triple-check that
everything was as I thought it was and that --forcing the command would
indeed do what I thought it would do.
Now I'm obviously biased by this experience, and that might make be
blind to a good reason to keep the current behavior. So I'm just humbly
asking whether we should keep the `fossil_fatal` for unsaved changes
when --keep flag is given.
Also, while looking at the code, I had the feeling that there is
unconditional disk-touching stuff that should be skipped with --keep,
but that's probably more debatable than the bias in the heat of the
moment made me think.
Natasha
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[Natacha Porté]

Hello,

Post by Richard Hipp

Post by Natacha Porté
I was recently in a very uncomfortable situation, with precious
uncommitted data in the current checkout and the need to change where
the checkout "current commit" points to.

That's what the "fossil update" command is for.

I'm afraid I didn't explain the situation clearly enough, or I have a
major misunderstanding of fossil commands.

I was under the impression that "fossil update" changes the "current
commit" not only in fossil book-keeping, but also in the file-system as
well, somewhat like "rebasing" the current set of changes to the
designated "current commit".

In shell terms, I understand "fossil update" to work like
$ diff -r virtual-reference/ ./ >/tmp/temporary-patch
$ fossil revert
$ fossil checkout $targetcommit
$ patch </tmp/temporary-patch

On the other hand, the situation in which I was is the checkout being
already in the desired state, but fossil having recorded a wrong
commit as current, so I would need a change of current commit while
preserving the whole file system, instead of preserving a diff.

In shell terms, I'm looking for something equivalent to:
$ mkdir ../tmp-checkout
$ cd ../tmp-checkout
$ fossil open /path/to/fosisl
$ fossil checkout $targetcommit
$ cp -r ../working-checkout/* ./
$ cd ..
$ rm -rf working-checkout
$ mv tmp-checkout working-checkout

I agree that it shouldn't happen, and indeed doesn't happen often, while
"fossil update" is routinely used when everything is well.

I happens to me most often (in situations where data is not precious) in
a situation like the one described by Warren Young, with several
checkout directories, and somehow a directory with an older checkout
gets newer files.

For example, I got this once when I tested a few independent features
which overlap in the affected code, before committing any of them. I
threw them together in the same checkout directory and do whatever
testing I felt needed. Later, when all the features but one are
committed, and the other checkout directories are used for other works,
I wanted to take this testing checkout, fast-forward to the branch head
without changing the files on disk, and I can directly commit.

It's a bit contrived, but less so then the other times I needed the
feature.

A "fossil update" then would try to reapply some changes that are
already in the checkout, unbeknownst to fossil, and I can't imagine it
would go well. Would fossil even realize some hunk are already applied
like patch does? Anyway, that would be a lot of a conflicts to solve,
while I know that the files on disk are actually merged.

On the other hand, the help says "The --keep option leaves files on disk
unchanged, except the manifest and manifest.uuid files." which seems to
do exactly the bookkeeping update I need.


Am I missing something?

Natasha

[Richard Hipp]

Post by Natacha Porté
On the other hand, the situation in which I was is the checkout being
already in the desired state, but fossil having recorded a wrong
commit as current, so I would need a change of current commit while
preserving the whole file system, instead of preserving a diff.

Huh. That does sound like a unusual state. I don't recall ever
getting myself into such a state before....

Post by Natacha Porté
A "fossil update" then would try to reapply some changes that are
already in the checkout, unbeknownst to fossil, and I can't imagine it
would go well. Would fossil even realize some hunk are already applied
like patch does?

Actually, Fossil does a pretty good job of recognizing when a hunk has
already been applied and ignoring it. If you do a "fossil update" and
find out otherwise - if you get a lot of conflicts - then you can
always back out using "fossil undo".

Thinking further - maybe I do get myself into your unusual state on a
regular basis. I do it like this:

(1) Make edits on Linux but do not commit.
(2) Copy the files to Windows and verify that they work there too.
(3) Run "fossil commit" on Linux.

At this point, the Windows machine has all the same files as the
newest check-in, but its "checkout" is from the prior check-in. I fix
this by running "fossil up". Fossil tries to merge the changes into
files that already has those changes, sees that all the patches have
already been applied, makes no changes to the files, and exits without
complaint.

Is that similar to what you are trying to do?

[Natacha Porté]

Hello,

Post by Richard Hipp

Post by Natacha Porté
On the other hand, the situation in which I was is the checkout being
already in the desired state, but fossil having recorded a wrong
commit as current, so I would need a change of current commit while
preserving the whole file system, instead of preserving a diff.

Huh. That does sound like a unusual state. I don't recall ever
getting myself into such a state before....

Indeed it is. To put it into perspective, I have a bit more than 700
"fossil update" in my main dev machine over the last 6 years, while I
encountered this unusal state less than 10 times, and only once did I
really could work around it.

Post by Richard Hipp

Post by Natacha Porté
A "fossil update" then would try to reapply some changes that are
already in the checkout, unbeknownst to fossil, and I can't imagine it
would go well. Would fossil even realize some hunk are already applied
like patch does?

Actually, Fossil does a pretty good job of recognizing when a hunk has
already been applied and ignoring it. If you do a "fossil update" and
find out otherwise - if you get a lot of conflicts - then you can
always back out using "fossil undo".
Thinking further - maybe I do get myself into your unusual state on a
(1) Make edits on Linux but do not commit.
(2) Copy the files to Windows and verify that they work there too.
(3) Run "fossil commit" on Linux.
At this point, the Windows machine has all the same files as the
newest check-in, but its "checkout" is from the prior check-in. I fix
this by running "fossil up". Fossil tries to merge the changes into
files that already has those changes, sees that all the patches have
already been applied, makes no changes to the files, and exits without
complaint.
Is that similar to what you are trying to do?

Yes, this is very similar to what I usually do (except I do it on the
same machine) and that's the bulk of my 700 "fossil update"s.

Now imagine you leave things as they are after (3) to do some non-dev
stuff (or some dev on other repositories), and you receive a serious
windows-specific bug report. You drop everything to work on it,
forgetting the "fossil up". You eventually make a fix in some code path
that is never reached on Linux, or for another reason you decide to
commit straight away.

Last time I was in this situation, "fossil up" would mark almost every
as a merge conflict. Maybe it got better since then? Anyway, you could
resolve the conflicts if there are not many of them, or you could copy
the final file somewhere, do "fossil up", and copy them back if there
are few files involved. That's how I dealt with the <10 times mentioned
above.

And then I had precious data, which happened to be spread over two dozen
files with on average half a dozen hunks in each, and no obvious way of
recognizing old or mangled data (that's the problem with data, instead
of code or understandable text). So I really missed a way of asking
fossil to just commit the files as they were but with another parent
than what was currently recorded as the current commit.


Natacha

[Andy Bradford]

Post by Natacha Porté
Now imagine you leave things as they are after (3) to do some non-dev
stuff (or some dev on other repositories), and you receive a serious
windows-specific bug report. You drop everything to work on it,
forgetting the "fossil up". You eventually make a fix in some code path
that is never reached on Linux, or for another reason you decide to
commit straight away.

First, will you provide a minimal working transcript of the problem
you're encountering?

Did you first create a new clean working checkout for your serious
windows-specific bug? Something like:

mkdir /path/to/newbugcheckout
cd /path/to/newbugcheckout
fossil open /path/to/repository.fossil

Make all your changes there so you don't taint your current working
checkout.

If you didn't do this, I highly recommend this practice.

Post by Natacha Porté
So I really missed a way of asking fossil to just commit the files as
they were but with another parent than what was currently recorded as
the current commit.

How? Is it not possible to just commit them against the checkout against
which such precious data was generated; that presumably was good before
you started generating new and uncommitted precious data, no?

Or did you start on a given commit (say 1), generate some new
and precious data without committing, and then decide to jump into
other work, perhaps less precious, commit just those things (perhaps
repeatedly), and then now you're at commit 10 and you decide you want to
commit your precious data? In that case, cannot you just do ``fossil
update 1'' and then commit the precious data? You'll have a fork, but
you can work out the details later if the goal is to get the precious
data committed. I'm not sure why this would ever result in conflicts, or
the inability to merge and commit the data.

Thanks,

Andy

[Warren Young]

Post by Richard Hipp
(1) Make edits on Linux but do not commit.
(2) Copy the files to Windows and verify that they work there too.
(3) Run "fossil commit" on Linux.
...
Is that similar to what you are trying to do?

Yes, this is very similar to what I usually do...
Now imagine you leave things as they are after (3) to do some non-dev
stuff (or some dev on other repositories), and you receive a serious
windows-specific bug report. You drop everything to work on it,
forgetting the "fossil up". You eventually make a fix in some code path
that is never reached on Linux, or for another reason you decide to
commit straight away.

Unless your emergency Windows version fixes overlap the changes made on that branch since the last “fossil up”, I think “fossil up” shouldn’t cause a merge conflict even if you delay it until just before you’re ready to check your changes in.

(You must do a “fossil update” here before Fossil will let you check in, unless you add --branch.)

At this point, I want a working test case showing the problem.

[Warren Young]

Post by Natacha Porté
$ mkdir ../tmp-checkout
$ cd ../tmp-checkout
$ fossil open /path/to/fosisl
$ fossil checkout $targetcommit
$ cp -r ../working-checkout/* ./
$ cd ..
$ rm -rf working-checkout
$ mv tmp-checkout working-checkout

That seems different from what you described in your later email.

I’m imagining a timeline that looks like this:

12:00:00 [12345] Bogus checkin
11:00:00 [abcde] Another bogus checkin
10:00:00 [fedce] Last point of sanity

It sounds like you are working on some code on top of [12345] but then realized that the last two checkins (in this example) are worthless and want to apply the current work on top of [fedce] instead, then possibly revert some of that work before checking in.

If that’s the case, Fossil lets you move those two bogus checkins to a hidden branch, re-exposing [fedce] as the tip of that branch:

$ fossil stash save
$ fossil amend --branch bogus abcde --hide --close
$ fossil up trunk # probably not necessary
$ fossil merge --cherrypick 12345 # optional
$ fossil merge --cherrypick abcde # ditto
$ fossil stash pop # bring uncommitted changes atop [12345] back
…manual fix-ups, test, etc…
$ fossil ci

I’m unclear about whether you want the “merge --cherrypick” bits here or just the “stash pop” part. Maybe in different situations, you want a mixture of all of these possibilities. For example, maybe the bogus checkins are only partially bogus, so that with a bit of editing they can safely be checked back in on that branch with the new “bogus” branch holding the failed attempt at solving the problem.

A good reason to do that sort of thing is when a checkin breaks a key branch like trunk that you need to be able to bisect against, so that every checkin must build on all platforms.

[Warren Young]

Post by Natacha Porté
I was recently in a very uncomfortable situation, with precious
uncommitted data in the current checkout and the need to change where
the checkout "current commit" points to.

Usually when I find myself in that situation, I just open a new checkout in a separate directory. I usually have several checkouts of any given Fossil repository on each development machine: tip of trunk and a checkout of the last stable release at the very least.

drh brought up “stash,” but I don’t like using that for truly precious uncommitted material, since it’s only committed to .fslckout locally, which means

a) it isn’t copied off-machine, as checkins are, if your local Fossil clones sync to a remote Fossil server

b) if you have a brain fart and nuke the current checkout tree, you lose the associated stash

When those worries matter, I generally check my partial feature in as a branch, with the checkin comment noting that the feature isn’t expected to work yet. Having copied the material both into the local repo clone and off-machine, I then feel safe in saying “fossil update” to move the local checkout to a different view.

[Natacha Porté]

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.

Post by Andy Bradford
First, will you provide a minimal working transcript of the problem
you're encountering?
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

[K. Fossil user]

Hi,
It is better if you could give to people the release you do use... (1.37 ?)
Some people do use a release that is inside some public servers which are not always up to date.Not to mention that most of the time the official (say stable) release is not the latest release which is less buggy ...
 
Best Regards

K.

De : Natacha Porté <***@instinctive.eu>
À : Fossil SCM user's discussion <fossil-***@lists.fossil-scm.org>
Envoyé le : Vendredi 7 juillet 2017 9h44
Objet : Re: [fossil-users] warning about unsaved changes with `fossil checkout --keep`

Hello,

*snip*
Have I left anything unclear?


Natasha

[Andy Bradford]

Post by Natacha Porté
(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.

Post by Natacha Porté
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?

Post by Natacha Porté
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.

Post by Natacha Porté
...
$ 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

Post by Natacha Porté

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

[Natacha Porté]

Post by Andy Bradford

Post by Natacha Porté
(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.

Indeed. Why I ask a tool to do something, I expect to have to deal with
the consequences of what I'm asking it to do.

Post by Andy Bradford

Post by Natacha Porté
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?

Indeed I am.

That or have the --keep flag not trigger the unsaved change check, in
case these wordings happen to not be exactly equivalent (the code is not
obvious on that point).


Natasha