7 ms·

I'm a forgetful person, so I commit very often but with label "tmp", and later I squash them all into 1 proper commit before pushing. I'm sure I'm not alone, so

I'm a forgetful person, so I commit very often but with label "tmp", and later I squash them all into 1 proper commit before pushing. I'm sure I'm not alone, so commit time can't be used as barometer.

lucb1e 7y ago
I never saw anyone do this. May I ask what the point is? If it's just going to be in your local version and you later have to do (a very small amount of) work to get it back into one commit, why bother committing random stuff intermediately at all?
- dharmab 7y ago
  Ever used a quicksave feature in a video game right before doing something destructive/risky/experimental?
  - lucb1e 7y ago
    Oh, I use undo in my editor for that kind of thing. But I guess if you want to make large changes, this might be one way of doing it. Pretty sure that's what 'git stash/pop' is supposed to be used for, but I don't use those either so I wouldn't know if that works well.
    - dharmab 7y ago
      git stash follows you around, while a temp commit is bound to a branch
- lolc 7y ago
  I mainly use the staging area for this. Not yet create a commit, but get the diffs out of the way.
samhh 7y ago
I dislike the apparent inability to label groups of changes with `git stash`, so instead before leaving a branch with in-progress changes I'll commit them all as "WIP". Then, when I return to the branch, I'll check if the previous commit was WIP (`git log -1`), and if so will reset it (`git reset HEAD~1`). It's the best workflow I've discovered for dealing with this problem, and it means that I don't lose my commit history which is otherwise very clean.
- glandium 7y ago
  git stash save my stuff (deprecated) git stash push -m "my stuff"
  - Sharlin 7y ago
    What GP wanted was to stash a history of commits, not just the current state of the working tree. `git stash` is fundamentally unable to do that.
    - johnmaguire2013 7y ago
      That's just called a branch. What GP described was committing all their changes into a single WIP commit.
      - wtetzner 7y ago
        They were describing many different WIP commits, and then later squashing them to a "proper" commit.
        johnmaguire2013 7y ago
        That's a branch. > Then, when I return to the branch, I'll check if the previous commit was WIP (`git log -1`), and if so will reset it (`git reset HEAD~1`). This is a single commit.
- Sharlin 7y ago
bstar77 7y ago
When I'm working on a new change I always create a new branch and (almost) always just work against one commit. I'll just keep amending that commit. I generally work out my tickets so that they are small enough that I don't have too many concerns with each branch, so maintaining a commit history isn't all that useful. I'm pretty sure I do loose out on the "looking really busy with lots of commits" in my github history tracking, but I could care less.
holtalanm 7y ago
i do this all. the. time. i'll squash multiple in-progress commits into one before submitting a PR.
- brianzelip 7y ago
  Do you use `rebase` for that?
  - ggregoire 7y ago
    Probably git reset.
    - xxandroxygen 7y ago
      nah most likely `rebase -i`
      - holtalanm 7y ago
        yeah, `rebase -i` for the squash.
cyphar 7y ago
I would suggest making use of 'git commit --fixup' or 'git commit --squash' which creates a commit that is specially-named such that you can later squash everything together with `git rebase --autosquash'. It's really transformed how I work on large patchsets.
- pertymcpert 7y ago
  Great tip, thanks.
- toyg 7y ago
  You da real mvp. It is ridiculous how many nice features git has accumulated through the years, but their discoverability is... not excellent -- partially because of how many options we now have. It's a vicious circle.
- vonseel 7y ago
  `git commit --fixup` very nice, I never particularly liked the workflow of "git rebase -i <hash>"
  - beatgammit 7y ago
    Eh, `git rebase -i master` (or some other branch) isn't so bad, or you can always rebase against origin/<your-branch>. But yes, --autosquash looks nice.
dangirsh 7y ago
You might like Magit's WIP feature: https://magit.vc/manual/magit/Wip-Modes.html https://magit.vc/manual/magit/Wip-Modes.html

lucb1e 7y ago

I never saw anyone do this. May I ask what the point is? If it's just going to be in your local version and you later have to do (a very small amount of) work to get it back into one commit, why bother committing random stuff intermediately at all?

dharmab 7y ago
Ever used a quicksave feature in a video game right before doing something destructive/risky/experimental?
- lucb1e 7y ago
  Oh, I use undo in my editor for that kind of thing. But I guess if you want to make large changes, this might be one way of doing it. Pretty sure that's what 'git stash/pop' is supposed to be used for, but I don't use those either so I wouldn't know if that works well.
  - dharmab 7y ago
    git stash follows you around, while a temp commit is bound to a branch
lolc 7y ago
I mainly use the staging area for this. Not yet create a commit, but get the diffs out of the way.

samhh 7y ago

I dislike the apparent inability to label groups of changes with `git stash`, so instead before leaving a branch with in-progress changes I'll commit them all as "WIP". Then, when I return to the branch, I'll check if the previous commit was WIP (`git log -1`), and if so will reset it (`git reset HEAD~1`). It's the best workflow I've discovered for dealing with this problem, and it means that I don't lose my commit history which is otherwise very clean.

glandium 7y ago
git stash save my stuff (deprecated) git stash push -m "my stuff"
- Sharlin 7y ago
  What GP wanted was to stash a history of commits, not just the current state of the working tree. `git stash` is fundamentally unable to do that.
  - johnmaguire2013 7y ago
    That's just called a branch. What GP described was committing all their changes into a single WIP commit.
    - wtetzner 7y ago
      They were describing many different WIP commits, and then later squashing them to a "proper" commit.
      - johnmaguire2013 7y ago
        That's a branch. > Then, when I return to the branch, I'll check if the previous commit was WIP (`git log -1`), and if so will reset it (`git reset HEAD~1`). This is a single commit.
Sharlin 7y ago

bstar77 7y ago

When I'm working on a new change I always create a new branch and (almost) always just work against one commit. I'll just keep amending that commit. I generally work out my tickets so that they are small enough that I don't have too many concerns with each branch, so maintaining a commit history isn't all that useful. I'm pretty sure I do loose out on the "looking really busy with lots of commits" in my github history tracking, but I could care less.

holtalanm 7y ago

i do this all. the. time. i'll squash multiple in-progress commits into one before submitting a PR.

brianzelip 7y ago
Do you use `rebase` for that?
- ggregoire 7y ago
  Probably git reset.
  - xxandroxygen 7y ago
    nah most likely `rebase -i`
    - holtalanm 7y ago
      yeah, `rebase -i` for the squash.

cyphar 7y ago

I would suggest making use of 'git commit --fixup' or 'git commit --squash' which creates a commit that is specially-named such that you can later squash everything together with `git rebase --autosquash'. It's really transformed how I work on large patchsets.

pertymcpert 7y ago
Great tip, thanks.
toyg 7y ago
You da real mvp. It is ridiculous how many nice features git has accumulated through the years, but their discoverability is... not excellent -- partially because of how many options we now have. It's a vicious circle.
vonseel 7y ago
`git commit --fixup` very nice, I never particularly liked the workflow of "git rebase -i <hash>"
- beatgammit 7y ago
  Eh, `git rebase -i master` (or some other branch) isn't so bad, or you can always rebase against origin/<your-branch>. But yes, --autosquash looks nice.

dangirsh 7y ago

You might like Magit's WIP feature: https://magit.vc/manual/magit/Wip-Modes.html https://magit.vc/manual/magit/Wip-Modes.html