This sums up my thoughts as well. Fossil breaks several flows:
- committing code at the end of the day
- making a temporary commit in order to checkout to another branch to work on things, etc
- committing code in order to pull onto another computer (admittedly a bit lazy, but I do this for small personal projects)
- fixing a commit that accidentally checked in binary files, secrets, etc. it happens!
I find myself checking out to different branches frequently to look at something for a colleague. I would much rather make a temporary commit to later rebase instead of using git stash.
Reading about fossil evokes a little bit of "you're holding the phone wrong", in my opinion. Git does lack things like issue trackers but I would rather not be limited by own tooling for little gain.
I don’t really understand the issue with doing this. Context switches sometimes take a while to get back to what you were working on, I’d rather not rely on local git stash state to get back to it. And if I do end up working on something else for a while then someone else might pick it up, they might as well have access to my WIP. Also the cost of a CI run is really low, there’s no practical downside to pushing it and letting the tests run on it so I have some more context about its current status when I or someone else picks it back up.
Stash is not reliable because it's not pushed to the server. If your computer breaks or you just want to move to a different computer, your stash won't follow you, but branch will.
I was responding to the comment that "making a temporary commit in order to checkout to another branch to work on things" is a "a Git bug."
But sure, I'll grant you that it has issues. Heck, Git is distributed, so if you're off-network, committing a bunch of code, and your computer breaks, it doesn't matter if you're using stash or commit. It all depends upon your use case.
You're not OP, but if they, needing to switch to a different branch for a bit, "would much rather make a temporary commit to later rebase instead of using git stash" I'm curious why. I know I used to do it because I didn't understand how stash worked, and then I read up on it, noted what the commands are in my listing (since I don't need to use it daily), and refresh my memory from my notes when I need to use it.
But I also prefer to do smaller commits, more often, and find history to be important. Likely because I do a lot of brownfield development and maintenance. And if I need to switch to another branch to help a colleague, and my code is such that I can't commit it yet, I'll either git clone to a new directory (if they're a new employee or someone just learning a project, and I know I'm going to be helping them a lot) or leverage git stash.
The main reason I prefer commits is because I frequently switch between computers, so I push up those commits. I also write detailed commit messages so I can come back a week or a month later.
Admittedly I haven't read that far into git stash's documentation, but commits + rebasing is far simpler in terms of cognitive load and doesn't require me to remember what I have in my stash on what computer, etc. All I need to do is push up the branch, and I can just rebase master onto the branch to pull in updates, etc.
- committing code at the end of the day
- making a temporary commit in order to checkout to another branch to work on things, etc
- committing code in order to pull onto another computer (admittedly a bit lazy, but I do this for small personal projects)
- fixing a commit that accidentally checked in binary files, secrets, etc. it happens!
I find myself checking out to different branches frequently to look at something for a colleague. I would much rather make a temporary commit to later rebase instead of using git stash.
Reading about fossil evokes a little bit of "you're holding the phone wrong", in my opinion. Git does lack things like issue trackers but I would rather not be limited by own tooling for little gain.