Background: Fossil's mv command does not rename files on disk, unless the option --hard is given or the setting mv-rm-files is on. That setting still defaults for fear of breaking existing scripts to off.

The subject comes up regularly in forum, last time yesterday.

The current behavior is different from most (all?) of the modern SCMs (git, hg, svn, pijul, darcs) and this tends to confuse new (and older) users, and is prone to create larger problems when the subsequent OS's "move" is forgotten.

For these reasons, I advocate that we change the default to on; users preferring the current behavior can set the setting to on, or use the --soft option.

EDIT: In the last sentence: users can set the setting to off, of course.

For these reasons, I advocate that we change the default to on;

FWIW: +1

I always set that flag here, but my understanding was that the reason for the default was that drh wanted to follow CVS’s conventions. Only if that is no longer a design goal can we flip this default.

drh wanted to follow CVS’s conventions

A more accurate characterization: Prior exposure to CVS had so conditioned my mind, that the --hard behavior never occurred to me when I was first designing Fossil. Then latter when --hard was proposed, it was made opt-in to avoid backwards-compatibility issues.

understood. but even CVS's successor (subversion) already did not keep/adopt this legacy behaviour presumably because it was found to be "suboptimal"?

in any case, what would be a fair assessment of the current situation, so many years down the road?

how much pain/friction would it cause today for how many long-time users to switch off mv --hard in their settings (in case they really prefer and rely on the current default) if the default were changed vs. how much pain/friction (and confusion!) does the current default behaviour cause for (hopefully continuously arriving) new users coming from other VCSes and expecting (and very possibly also preferring) "standard" mv behaviour? I really believe it would be a good (small) thing to change the default in the future.

I'm all for it yes, but maybe only for new repos / new clones, so that your existing behaviour doesn't change unexpectedly.

Even if I never bother to turn on this mv-rm-files and got used to the legacy way, I'm in for it also.
(I never used git or any other modern scm, I came directly from CVS)

but maybe only for new repos / new clones

I think this would be a lot more confusing.

If it's default globally, someone could get a kind of moment of surprise once, if it behaves differently on different repo, those surprising moment could happens many times on a long time span, especially that it would not be obvious that behaviour happens only on new repo or clones.

Also, moving files in repo is relatively rare, creating/cloning repo can be rare compared with using existing repo depending on user, so it could take a while before one realized that the behaviour is different on some repository.

I even don't see a case where someone would want the mv-rm-files setting set differently on different repositories in the first place. Probably it's possible now just because we don't have global only settings ?

understood. but even CVS's successor (subversion) already did not keep/adopt this legacy behaviour presumably because it was found to be "suboptimal"?

Trivia: fossil was directly inspired by CVSTrac, so initially inherited more from CVS than SVN. (Funnily enough, CVSTrac's source code is now hosted in fossil.)

I have moved files on the OS and then via fossil. Having it being a single operation would be neat, but I don't find the need to move files that frequent.
However, it being similar to the other players makes sense.

What's the output like if you have this enabled? It might be nice to have it report the file was moved on the OS and renamed in fossil, if that's not already present.

The "fossil undo" command does not (currently) undo a "fossil rm --hard". Perhaps that should be fixed before "--hard" becomes the default?

That would make Fossil internally consistent with itself. Every command that modifies the state of a check-out should create undo data by default (which is overridable in some commands with --disable-undo).

Not showing up in the standard fossil help output probably contributes to mv and rm being the first reach. Even still, your proposal would require changing the current behavior of commands:

The 'rename' command never renames or moves files on disk, even when the
command line options and/or the 'mv-rm-files' setting would otherwise
require it to do so.

The 'forget' command never removes files from disk, even when the command
line options and/or the 'mv-rm-files' setting would otherwise require it
to do so.

These are effectively synonyms for fossil mv --soft and fossil rm --soft.

Glad to see it changed. :-)

Not synonyms, or at least put it the other way around: mv --soft is a synonym for rename. But why would you want to do that?

I believe a better way to think of this is that rename and forget are fundamental VCS operations to say that when the current checkout is committed rename x y means the file previously known as x is now to be known as y and forget f means that the history of file f comes to an end. mv combines rename with one of its possible implementations viz the unix style mv, and rm|delete (those really are synonyms) combines forget with one of its possible implementations viz the unix style rm.

Compare this with fossil add: You are supplying information to the VCS that a file f will appear and we want its future lifetime to be tracked. In this case there is no obvious possible implementation so there is no associated command.

rename and forget should be the prime entry points with regard to the help text, the other commands are just for convenience where a simple implementation is suitable, and appear as 'see also' in the command they relate to.

Notice that described in this way you don't need --hard and --soft and their associated setting at all, other than for compatibilty reasons. Perhaps even try to address the issue initially with just changing the documentation?

If we gave a bit more description of what effect these commands have when viewed in a timeline perhaps newcomers from Git and friends would realise sooner that the similarly named commands from their own VCS might not be as close to the Fossil offering as the names suggest.

I've used fossil mv quite a bit and learned the hard way early on: 1) always use fossil to rename &/or move files around 2) always include --hard to actually make the change in the OS file system/checkout. Both behaviors were counter intuitive to me.

Perhaps fossil's change log should have a section like some other projects where some changes in behavior are at the top, like OpenSSH's "Potentially-incompatible changes" section. Thus folks who delve into these matters can read about them first before installing the latest version. Admittedly it seems people around here are (re)building fossil hourly/daily/weekly so they might catch it sooner, but my guess is not all fossil users are on the bleeding edge. So the people they look to will be able to adjust their workflows if need be, before their end users upgrade.

My repo of recipes had grown to be a long list and it was time to categorize them in folders. I don't have a fancy renaming script yet so it was all done at the command line. Thankfully 'f' is aliased to fossil, saving a few keystrokes, and thanks to Stephan, I added the global setting (now redundant with this change) to make fossil mv always --hard, saving a few more.

Fossil is awesome to fossilize one's data, but not all of its behaviors should necessarily be ossified. :-)

I've used fossil mv quite a bit and learned the hard way early on: 1) always use fossil to rename &/or move files around

Question as someone pretty new it: could there be a heuristic to detect these cases for 1)? If in the same commit a file is removed and a file with the same checksum is added, that probably should be a rename. Maybe at least ask the user if they want to use rename first, before committing?

But tricky.

If mv were to be made undo-able, do we consider the content of the file(s) part of the modified state or not? For example if I fossil mv a b and then edit b, should undo restore the original content of a? If we think it should, then that means redo has to have access to the edited version of b.

This is a consideration for how most undo commands work though, isn't it?

It would revert to the original state of a presumably prior to the move, not move the new b back to the old name.

... Obviously there is no way for vi to clear ..

May be the undo command could issue a warning (or a kind of are you sure y/n prompt) if it detect that some file on the disk are different from what was saved on the undo stack ? So the user can take decision if he is willing loose the edit was done after the fossil mv command ?

(also thinking out loud...)

"revert" takes you all the way back to the last commit. "undo" just takes you back one step.

For these reasons, I advocate that we change the default to on;

yes please