Hacker News Reader

Comment by dilap | Hacker News Reader

Along similar lines, I've adopted a hyper-frequent commit pattern in git. I do a bunch of meaningless micro-commits as I'm making progress, and then rewrite them all into one or two meanginful commits once I've reached a working state of whatever I was trying to do.

I find it's helpful for not losing work / easily backing up if as I'm going along I realize I want to change approach.

(For the micro commit I have a git command "git cam" that just commits all changes with the message "nt". Then once I'm ready to do a "real commit", I have "git wip" which rolls back all the nt commits but leaves them in checkout; then I can make one or two "real" commits.)

I wonder if dura would be even better, or if the commit frequency would end up being too fine-grained and obscure?

View on HN

What you're describing is how git should be used. I would add it's important to push your branch to the remote just in case something happens to the local copy. I tend to squash/rebase to get the same type of results, but I can't imagine not saving work regularly or being concerned with the commit history while I'm actively working.

different strokes for different folks. I like to use my staging area as "I want to save this" until I get to a logical stopping point in my work. Then I commit it with its descriptive message. This way I can diff/reset against master while making progress, and show a nice clean progression of my work for who reviews it.

also, sometimes I just lump the whole thing into a PR because there arent more than one logical unit.

You can still get do what you want if you commit every 60 seconds (or whatever). It's just about postponing any and all cleanup activity until you're ready to shared it with reviewers/the world.

(... but of course, by all means do what works for you. Just be aware that you might be missing out on something because you're artificially constraining your workflow.)

A commit every 60s sounds terribly inconvenient unless it’s automatic. I share OP’s workflow patterns and it works for me.

I also don’t use an IDE.

I don't mean 60s literally. I mean arbitrarily small commits at your own convenience.

You don't need to have even remotely working code when you commit, is the point. You just commit whenever. (It's almost like saving files, just commit.)

I think the word 'commit' might have been a mistake, now that I think about it. Maybe 'snapshot' would have been better.

yeah, I mean its situational and sometimes I will do that, but 90% of the time staging does what I need for temp backups

I usually commit often locally and push to remote right away. Then when I want to open up my PR, I use `git reset --soft <target>` where target is the local version of the target branch in my PR. That resets all the commits, but keeps all the changes in the staging area, and then I can clean up my history. Then I force push to override what's there.

This works well for my workflow because we squash all commits into target branches and don't really rely on commit history auditing during review. I understand that's not the case everywhere, but works for me.

I never considered soft resets for my work flow (rewrite history with rebase -i). Funny how I use it for other things, but not this. Thanks!

sure thing. I actually just learned about it about a year ago and before then I was rebasing interactively too - this is so much easier!

I just gave this workflow a shot and it was great. Thanks for the tip! Do you use anything for committing more granular chunks of code? I'm just committing groups of files but after reading about magit on other hn threads, I feel like I could do better.

edit: added question

I use the local history in Jetbrains/IntelliJ/PyCharm all the time. Can use it on a current file, or even mark a folder if you accidentally deleted something.

It annotates the checkpoints with metadata as well. Like "this is how the file looked when you ran a test that failed".

Clearly, my JetBrains IDEs paid themselves multiple times by saving me from « oh shit » situations. Best investment my employer did without never knowing it :D

Local history saves my bacon about once a month. It's incredibly helpful as it lets me adopt a fearless refactoring approach knowing that I can always get back.

I just checked, it looks like there is a VSCode plugin that does this: https://marketplace.visualstudio.com/items?itemName=xyz.loca...

Repo here: https://github.com/zabel-xyz/local-history

Doesn't appear to mark checkpoints with metadata, though (test failed/passed, etc.).

I'll just throw out there that ever since I picked up Doom Emacs and the associated Magit, I have been doing the same thing and loving it, I'll commit every time I finish writing a logical scope of code, and then commit and push and know that everything is there in case anything happens, it also has made my commit comments much more descriptive as I know am actually able to describe exactly what the commit has done beyond "Added feature X, refactored function Y". Big fan of the continuous commit workflow.

I've tried that as well. For me it was really difficult as I use the current changes quite a lot, and it makes it a lot more difficult to grasp the work I've done so far without having a meaningful change set.

I keep a draft PR open to keep track of this. Not has nice as vs-codes diff tool though.

You can still use VS Code's diff if you have the GitHub Pull Requests extension: https://marketplace.visualstudio.com/items?itemName=GitHub.v...

Anything that would allow a similar workflow in JetBrains IDEs?

you can use separate dev/release branches, and do something like "git diff master" (if you dont git push, you don't even need a separate branch, git diff origin/master works, but you lose half the point of frequent commits then)

I do something similar but a little more manual that your solution. I `git commit -am "WIP"` to save random, odd-ball intermediate working states. Occasionally the commits get real messages but I try not to let it interrupt the flow.

Then when I'm ready to commit or cut PRs, I just squash them all down if it's trivial. If it's a bigger change: I push things to a backup branch, `git branch Branch-BK`, reset to a base commit, and use difftools to pull over the subset of changes I want and commit them repeatedly until there's no diff left.

I have a `git snap` command that's similar to your `git cam` command with a small twist. The commit is added to a special snapshots branch that isn't checked out. I push the snapshots branch and don't rewrite it, but rather keep it around as an accurate chronological record of things I've tried, warts and all. I also like that `git diff` continues to show the changes compared to the last "real" commit this way.

Edit: I guess my script is somewhere between your `git cam` command and Dura in terms of functionality and complexity.

I do something similar, but with larger intermediate commits than yours and more meaningful messages. Then at the end, I do an interactive rebase, squash the ones I don't care about, and reword the final commit message based on the hints I left myself in the squashed ones.

I do a combination of the two: the first commit gets a meaningful (but still draft) message, and their follow-ups are all committed with "." as a message - but only until "switching gears", i.e. until a commit comes that is logically separate from the bunch before it. Those commits that have messages then provide logical milestones for squashing.

This breaks down sometimes if you have to switch back and forth between different parts of code, breaking the linear sequence. But even then, the messages make it easier to connect the pieces when it's time to clean up history before the pull request.

Can you share how these are aliased? I love git and only recently became more of a daily user of it in the command line.

probably just an alias in .bash_profile, here's the first thing I found in google: https://www.moncefbelyamani.com/create-aliases-in-bash-profi...

Yup, check out my comment here: https://news.ycombinator.com/item?id=29786798

(I use just external scripts rather than git aliases because I find it a little nicer to work with; git has a feature where if you enter "git foo", it will look for a command "git-foo" to execute.)

It seems like you could just use the index.

I.e. just use "git add -A" instead of "git cam"

Then you don't need "git wip"

For me, having it be a real commit is nicer -- can switch between branches, push if I'm switching computers, look at history, &c.

Might be a useful workflow for you to use fixup commits to rebase automatically helps you out

Yep, exactly. My terminal autocompletes to previous commands, so it's pretty easy to get to 'git commit --fixup HEAD', likewise for a rebase with --autosquash.

This workflow sounds similar to the one we use at my company! I use the git-ps tool we made to make stacks of usable micro-commits, and using the tool to keep things logical and working as things change and the code develops. https://github.com/uptech/git-ps

I don't quite understand how it is intended to be used, if you have time can you describe your work flow with the tool?

Have you considered using `git commit --amend --no-edit` after making your first commit? It simplifies the unwinding step.

This is pretty much my workflow, too. I’ll make some changes, `git commit -m wip`, and then `g can`. When you’re ready to prepare the PR/diff, `reset HEAD^`. Then, a few cycles of `add -p`, `commit -v`.

`commit --amend` and `add --patch` are super powers!

If you do this, and find you want to go back to 3-4 commits ago, you need to dig around in the reflog for it.

Ah yeah, that's a totally fair critique. Everything in moderation, I suppose. :)

I must avoid those situations by making a new commit when I anticipate wanting to keep the reference to that point in work accessible.

I do dive into `reflog` maybe once or twice a quarter, but as far as I can remember, I only go there as an immediate reaction to tired-brain mistakes.

Do you have those commands handy by chance? :D

It's usually something like:

    git status && git add -A git commit -m "checkpoint" --no-verify

I include `git status` so I can see what's being committed. `--no-verify` is used to skip any pre-commit hooks.

You can use `-v` on the add to see what it’s doing instead of the extra status

Sure thing https://gist.github.com/erinok/0247c134a57acdb2e2daafdf1d77a...

It's a handful of commands because git-cam and git-wip referenced other little utility scripts, so hopefully I got them all. Probably it would be easy to rewrite to be standalone.

I'm on a mac, and I have ripgrep installed as "rg". Ymmv, glhf :-)

So:

"git cam" commits everything with message "nt"

"git wip" undoes all the nt commits but leaves the results staged, ready to be commited as a single properly worded commit (or play w/ what's staged and do as several commits)

This is also my pattern. To further assist with this, I wrote a short(ish) rebase script intended to be run when you want to squash your series of commits, also bringing your local branch up-to-date with the upstream. It relies on your initial commit in your feature branch having a commit message which corresponds to the branch name, but that's it. This does a great job of minimising unnecessary merge conflicts, even after working offline for an extended period.

https://gist.github.com/nicois/e7f90dce7031993afd4677dfb7e84...

I would like to go this approach. I simply forget to commit until I’ve wrapped up something big, but I’d like to submit more frequently so others can see my work. Is there something that will remind me to commit? Esp. In VSCode

> Along similar lines, I've adopted a hyper-frequent commit pattern in git. I do a bunch of meaningless micro-commits as I'm making progress, and then rewrite them all into one or two meanginful commits once I've reached a working state of whatever I was trying to do.

Aren't you describing a feature branch? That frankly sounds like git 101.

Nope. A feature branch is still expected to have meaningful commits, and is usually used for collaboration between several coders. Its history doesn't get rewritten.

What OP describes is a temporary work branch that belongs to a single person, and has a bunch of meaningless commits. So nobody else should be using it - or if they do, they need to sync with the owner, since the latter can squash or otherwise mutate commits at any time.

> A feature branch is still expected to have meaningful commits, and is usually used for collaboration between several coders.

No, not really. In fact, some issue tracking software equate feature branches with tickets, worked on by a single person.

> What OP describes is a temporary work branch that belongs to a single person, and has a bunch of meaningless commits.

Aka a feature branch.

I guess we'll have to agree to disagree, then. In my 20 years in this industry, I've never seen a feature branch like that.

You can do this already with git natively.

https://thoughtbot.com/blog/autosquashing-git-commits

I think what you're doing is better because it's more explicit. I feel like Dura is yet another tool for people that don't know, and don't want to learn, Git.

Eh. I do tens of commits and then squash into 1 or a few, sometimes by resetting back and a few add --patch and sometimes by interactive rebasing.

But I can see times where Dura could be kind of nice. When I'm doing CAD or other not-very-source-code things, having a few snapshots be grabbed along the way sounds nice. Going to try and git commit in intermediate states feels a little too mode-switchy to me.

Reply on news.ycombinator.com