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

[Natacha Porté]

on Friday 07 July 2017 at 22:14, Andy Bradford wrote:
> Thus said Natacha Port? on Fri, 07 Jul 2017 09:43:56 -:
> 
> > (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.

> > 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
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[Andy Bradford]

Thus said Natacha Port? on Fri, 07 Jul 2017 09:43:56 -:

> (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 

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 

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

[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é <nata...@instinctive.eu>
 À : Fossil SCM user's discussion <fossil-users@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
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


   ___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[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.

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

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

[Warren Young]

On Jul 6, 2017, at 1:30 PM, Natacha Porté  wrote:
> 
> on Thursday 06 July 2017 at 14:01, Richard Hipp wrote:
>> 
>> (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.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[Andy Bradford]

Thus said Natacha Port? on Thu, 06 Jul 2017 19:30:29 -:

> 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.

> 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
-- 
TAI64 timestamp: 4000595ea731


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[Natacha Porté]

Hello,

on Thursday 06 July 2017 at 14:01, Richard Hipp wrote:
> On 7/6/17, Natacha Porté  wrote:
> >
> > 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.

> > 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?

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
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[Richard Hipp]

On 7/6/17, Natacha Porté  wrote:
>
> 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

>
> 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?


-- 
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

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

[Natacha Porté]

Hello,

on Thursday 06 July 2017 at 10:59, Richard Hipp wrote:
> On 7/6/17, Natacha Porté  wrote:
> > 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 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[Warren Young]

On Jul 6, 2017, at 8:38 AM, Natacha Porté  wrote:
> 
> 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.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[Richard Hipp]

On 7/6/17, Natacha Porté  wrote:
> 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.

>
> 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
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>


-- 
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