Fossil Forum
Post: Fossil stash applies to multiple commits?
I was looking for a way to split changes within a single file:
While coding a feature I found two simple bugs and fixed them right there in about a minute each. I found that with Fossil stash diff and vimdiff I could select the lines to apply, and then commit just those changes, however Fossil stash would stash my commits all the way to the state when I invoked Fossil open. That's more than 30 commits. On the other hand I couldn't call Fossil close with the uncommited changes. Needless to say, this method wouldn't work unless I close then open the repo after each commit. I'm not sure if this how Fossil stash is supposed to work or if I'm missing something.
I'm running Fossil 2.27 [99675884a9] 2025-09-30 on MSYS (a modified Cygwin).
You have to be misattributing the conditions here, because stash doesn't work like that at all.
Stash affects the same things that would be gathered up as part of a checkin: every difference in the current checkout relative to the parent commit.
The two leading third-party solutions for a lack of a commit-splitting feature in Fossil are fnc stash and patchouli.
I will test it again as I make commits later.
I would also suggest fsl with the cookbook entry for the record interceptor. The blurb for the interceptor says:
During development it is sometimes convenient to be able to commit only some of the changes in the current working directory. Fossil allows to select some files to be included in the next commit, but it is not possible to select only few changes in one file. Note that it is arguable whether such partial commits are a good thing or not because they encourage the creation of checkins with untested code.
This modification adds a record command, which mimics Mercurial's record extension. It allows to interactively select hunks to be included in the next commit.
fsl takes a little work to set up but opens a number of enhancements to your fossil workflow.
On the other hand I couldn't call
Fossil closewith the uncommited changes.
It's a safety measure to make sure you don't lose data. For what it's worth though, fossil close doesn't do a whole lot other than remove the .fslckout file from the working directory. It's often easier to just forget the command exists and delete the directory from the OS side. Your global fossil database would briefly be out-of-sync with the actual file system state, but that'll resolve itself as soon as it goes looking for the checkout.
Needless to say, this method wouldn't work unless I close then open the repo after each commit.
Stashes are part of the .fslckout file; if you used fossil close, you would lose all of them.
Stashes record what the checkout was when they were created, but they don't depend on you actually being on that particular checkout to apply (though you may get merge conflicts). They also don't stash commits, they only stash changes made to a working directory. Once you commit something to Fossil, it's in the permanent record.