Explain alternative to stashing

[hkrutzer]

Wiki page

https://github.com/arxanas/git-branchless/wiki/Workflow:-stashing

Subcommand

No response

Description

Hi,

The page on stashing says

TODO: explain an alternative to stashing commits with git-branchless.

I don't actually using stashing because I always forget the flags to include everything, instead of just staged changes. I also want the changes to stay on the branch I am on, and I like that they're recorded. Instead I have these aliases:

wip = "!git add .; git commit -m WIP"
unwip = "![[ $(git log -1 --format=%B) == WIP ]] && git reset --soft HEAD^ && git status || echo HEAD is not a WIP commit"

Generally I use this when I have some code that I never want to publish, for example containing debug statements, but I need to do something on a different branch.
It would be great if you could expand on how to achieve this with git-branchless.

[mlcui-corp]

Some notes for this workflow:

• git record commits all tracked files by default if none are staged, which might simplify the wip alias.
• I personally find it hard to keep track of WIP commits without a description, so my WIP commit messages are typically something like "WIP: goat teleportation".
• unwip is an interesting workflow - I typically git amend my WIP commits until they become squash-into-parent-able, or submittable with a git reword.
• jj WIP commit / stashing workflow is very intutive (WIP commits are automatically created, jj edit is effectively unwip) and should be quite familiar to git-branchless users.

[arxanas]

TODO: explain an alternative to stashing commits with git-branchless.

The main thing that this is referring to is more or less what you're already doing. Stashes in Git are a hacked-on feature that don't interact well with the rest of Git, so it's better to use regular commits for the same thing. I had intended to implemented a -s/--stash option for git record which would create the commit and then immediately check out the parent commit (possibly generating an automatic commit message from the file names or something like that) and a git uncommit command which would hide the commit and leave the changes in the working copy, but I never implemented either of those.

Like @mlcui-google says, you might want to check out jj because of how it handles the working-copy commit. Also like @mlcui-google, I write brief commit messages of the form temp: do something, and I often stack several provisional commits in a row, and later clean them up and create "proper" commits out of them.