Hacker News Reader

Comment by wiradikusuma | Hacker News Reader

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.

View on HN

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.

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.

`git commit --fixup` very nice, I never particularly liked the workflow of "git rebase -i <hash>"

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.

Great tip, thanks.

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.

Temp branches or tags are probably the "proper" way to stash a history of changes in git. `git stash` is mostly a convenience feature for when you want to quickly clean up your working tree to eg. pull latest changes from a remote.

I like the approach of creating a new temporary branch for changes I need to stash. When I come back to the work I usually bring the changes back to the branch I'm working in with `git cherry-pick -n <commit hash>`. The -n flag cherry picks the changes over without making a new commit, so I can finish whatever I was doing and then make a proper commit.

I use stgit for this kind of thing.

You can also use `git commit --amend` to clean up a WIP commit.

I hate stash because it’s too easy to accidentally pop. I just use a lot of branches, get familiar with git rebase, and learn about git reflog in case I screw up.

git stash save my stuff (deprecated)

git stash push -m "my stuff"

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.

That's just called a branch. What GP described was committing all their changes into a single WIP commit.

They were describing many different WIP commits, and then later squashing them to a "proper" commit.

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.

Yes I think your workflow is more correct than using stash. Work that is fully intended to enter the branch should be in commits, not stashes.

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.

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

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

Do you use `rebase` for that?

Probably git reset.

nah most likely `rebase -i`

yeah, `rebase -i` for the squash.

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?

Ever used a quicksave feature in a video game right before doing something destructive/risky/experimental?

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.

git stash follows you around, while a temp commit is bound to a branch

I mainly use the staging area for this. Not yet create a commit, but get the diffs out of the way.

Reply on news.ycombinator.com