Is there anything like stash but for untracked files in the source tree?

No. The the clean command and the unversioned command may deal with unmanaged files, but fossil otherwise leaves those files to your own management. If you want fossil to manage them, it needs to be told to (by adding them to the repository). There are countless ways to do what you're asking outside of fossil, e.g. moving their directories or zipping them up (the zip command's -o flag will remove them from the filesystem when they're zipped).

Tell us what problem you're attempting to solve and perhaps we can suggest a way to solve it which doesn't require stash acrobatics.

Before commiting i want to see and be able to examin all the files going to commit and only theese files. Working tree allows to examine, but i have to remember, which files are added for commit, ls command list files ready to be commited, but i cannt examin them.

I work with text files in subfolders, not code.

Before commiting i want to see and be able to examin all the files going to commit and only theese files.

fossil status

and its alias:

fossil changes

shows exactly that.

but i cannt examin them

fossil diff

shows the contents of modified or added files. To get a colorized diff, try:

fossil diff -tk # requires a working tcl/tk installation

or

fossil diff -by

shows a side-by-side diff in the browser. Remove the "y" part to get a non-side-by-side diff.

I want to see all of them, not only those different from previous commit

From the status help:

Filter options:
   --edited          Display edited, merged, and conflicted files.
   --updated         Display files updated by merge/integrate.
   --changed         Combination of the above two options.
   --missing         Display missing files.
   --added           Display added files.
   --deleted         Display deleted files.
   --renamed         Display renamed files.
   --conflict        Display files having merge conflicts.
   --meta            Display files with metadata changes.
   --unchanged       Display unchanged files.
   --all             Display all managed files, i.e. all of the above
...

Note that last line.

Edit: there are more options than that. Those are just the ones which seem most relevant to what you're trying to see.

Thanks a lot. So I can see all the files ready to be included in commit.

Just curious, I'm not a programmer, how do you test and build app before commiting, if not all the files in working tree are marked to be commited? How to exclude possible influence of untracked files when running test on working directory? I read the discussion why fossil doesn't like partial file commits, but same logic doesn't work for partially commited directories?

Just curious, I'm not a programmer, how do you test and build app before commiting, if not all the files in working tree are marked to be commited?

Ideally by keeping checkins small enough that all such changes can be seen in the "status" output, but we don't live in an ideal world ;). Even programmers are human 😳 and we sometimes fail to add all necessary files, in which cases checkins like this one are necessary to fix such oversights. That's just part of the process.

That said: the relatively new patch command can be used to push all local changes to a second checkout (either on the local machine or a remote one) so it's possible to check for things like missing files that way. (Reminder to self: remember that next time.)

In general, i find it good practice to do "fossil add" as soon as a new file is added to my checkout if that checkin is intended for the next commit. (But, as is demonstrated by the above checkin link, i don't always remember to do so.) If the file turns out to be useless, "fossil rm" can be used to unqueue it before it's ever checked in (in which case it never becomes part of the project history).

I read the discussion why fossil doesn't like partial file commits, but same logic doesn't work for partially commited directories?

Fossil doesn't track directories. It tracks only (whole) files, and only the files it's explicitly told to. For it to second-guess the user about which files it should or should not be managing would be madness. It's not fossil's responsibility to decide what needs to be managed, only to manage precisely what it's told to manage, no more, no less.

You can run fossil changes to see what files in the checkout have changed compared to the repository. After you decide which of them you want in the next commit, run fossil commit file1 file2 file3... to commit only those.

Not too bad, just a bit of gymnastics:

#!bin/bash
#
# Move unmanaged files to a safe place.
# Assumes you are in an open checkout.

mkdir -p ../safe \
&& rm -rf ../safe/* \
&& mv -t ../safe $(fossil clean --dry-run | cut -c -f 25-) \
&& fossil clean
echo Retrieve from safe with mv -tR ./ ../safe/*

(untested)

Or similar script: open a nested checkout of same repo in a subdir, then use fossil patch pull ../. to bing the change and test in the fresh checkout. This way, the original checkout remain untouched.

For myself, I have the habit to systematically run "fossil status" and "fossil extra" with a well maintained "ignore-glob" file before to commit. This catch most of those kind of mistakes.

Or if you prefer not using a script, you can keep this clean checkout subdir around and do:

fossil revert && fossil clean && fossil patch pull ../.

And test before your next commit.

That probably works, but looks a bit scary to my anonymous eye...

It would "feel" cleaner (also untested) to do something like the previous suggestion of a new checkout; and then a variant of "fossil diff | patch" to get only the will-be-commited changes from the working directory, into the new testing directory.

That is, something along the lines of

cd "$workdir"
repository=$(fossil info | sed -n '/^repository: */s///p') # probably there is a better way?
mkdir "$testdir"
cd "$testdir"
fossil open "$repository"
cd "$workdir"
fossil diff -v | ( cd "$testdir" && patch -p0)
cd "$testdir" # and test until happy

"workdir" is untouched. "testdir" can be wiped-and-recreated at will (although a "fossil close" might not go astray if a new directory name is used each time.

Does that fit what is wanted? (With shell "-e" and "pipefail" and other safety measures added, most likely.)

Cheers,

fossil diff -v | ( cd "$testdir" && patch -p0)

FYI: fossil patch pull src/dst (or push for the other way around) will do that in 1 command and will also update dst to same version as src checkout first.

fossil patch pull|push can also be used through ssh when src or dst checkout is on a different host.

see: fossil patch command usage.

(same anonymous here)

So it does, thank you for that.

In this case, it looks like it would be either

cd "$workdir"
fossil patch push "$testdir"

or

cd "$testdir"
fossil patch pull "$workdir"

and then $testdir has the same "fossil changes" as $workdir, but no "fossil extras", so it should be good for testing that the next "fossil commit" in $workdir will be standalone-good.

That sounds like it might be what the original poster is looking for?

(So long as they are happy to have a second checkout that is "just" for testing, which I suspect is the common case.)

Cheers,