Hacker News Reader

Comment by parpfish | Hacker News Reader

What do you do with the commits that are “incomplete”?

I frequently get halfway through building something, but the. A more urgent project comes up and i need to commit my half-done non-functional work so I can hop onto a different branch

View on HN

I usually use stash for this stuff. But alternatively you can commit and then come back and squash / rebase to clean up the commit history.

Are you familiar with working trees[1]? It may be a nice thing to utilize if you’re frequently jumping around on different branches.

[1] https://www.git-scm.com/docs/git-worktree

I stash half-baked work to keep it separate from quality commits. When I come back to the stash, I may or may not like where it was going and decide to build on it.

Stashing always makes me nervous.

For some reason it feels ephemeral and I worry that I’ll lose the stashed changes like when you accidentally overwrote the copy/paste clipboard

Yes, I generally don't use it much, because it forces me to remember that I have stashed work.

I used to feel this way because I lost work to `git stash pop` in the past, but there is now a nice feature where if you `git stash pop` and it doesn't cleanly applies, git keeps the stash and I use it more often now.

That said for me the stash is usually used either for temporary stuff (eg taking my current work to another branch) or for things that might be useful to reference later but I will rewrite differently anyways; stuff I want to keep goes into a WIP commit.

Committing everything to a new (temporary) branch, and returning to your current branch, costs nothing and saves the headache of stash's weirdness.

Git stash is indeed more dangerous than branching. Stashes don’t go into the reflog, and so you lose the primary safety net that git offers. I’ve watched people get into a bad state with stash and end up losing work. The stash documentation says “If you mistakenly drop or clear stash entries, they cannot be recovered through the normal safety mechanisms. However, you can try the following incantation to get a list of stash entries that are still in your repository, but not reachable any more: <git fsck ...>” https://git-scm.com/docs/git-stash

I know stash feels easier to a lot of people, and that’s a valid reason, but it’s really no more typing or thinking to use branches instead, it just might require changing habits.

I create "WIP" commits, and then I squash those. I squash intentionally to clean up commits that should be together.

I take all "WIP" branches and rebase them as needed onto the 'latest' development. Any continued work on those branches will have to be compatible with all released code, so deal with any issues -- i.e. merge issues during a rebase -- now, rather than later when you try and submit a PR.

As a team leader, I prefer to avoid "a lot of" WIP branches, but I just expect developers to rebase their WIP onto dev, etc.

Oh, and I really really dislike "merging" develop into the WIP branch. This accomplishes the same thing as "rebasing" the WIP branch onto develop, but it leaves a horrible mess behind.

Frankly, I don' give a hoot about some "history" of work. In the end, I care about the unit of work encapsulated in that WIP branch, and that unit must always add on top of develop. Rebase just makes that super clear.

Reply on news.ycombinator.com