4 ms·

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

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

erik_seaberg 2y ago
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.
- parpfish 2y ago
  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
  - recursive 2y ago
    Yes, I generally don't use it much, because it forces me to remember that I have stashed work.
  - deredede 2y ago
    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.
  - klyrs 2y ago
    Committing everything to a new (temporary) branch, and returning to your current branch, costs nothing and saves the headache of stash's weirdness.
  - dahart 2y ago
    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 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.
deleted 2y ago
[deleted]
mrinterweb 2y ago
I create "WIP" commits, and then I squash those. I squash intentionally to clean up commits that should be together.
kutenai 2y ago
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.
kcrwfrd_ 2y ago
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.
ngai_aku 2y ago
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 https://www.git-scm.com/docs/git-worktree

erik_seaberg 2y ago

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.

parpfish 2y ago
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
- recursive 2y ago
  Yes, I generally don't use it much, because it forces me to remember that I have stashed work.
- deredede 2y ago
  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.
- klyrs 2y ago
  Committing everything to a new (temporary) branch, and returning to your current branch, costs nothing and saves the headache of stash's weirdness.
- dahart 2y ago
  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 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.

deleted 2y ago

[deleted]

mrinterweb 2y ago

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

kutenai 2y ago

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.

kcrwfrd_ 2y ago

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.

ngai_aku 2y ago

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 https://www.git-scm.com/docs/git-worktree