7 ms·

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 the

• jwineinger 5y ago
  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.
  • int_19h 5y ago
    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.
• DarylZero 5y ago
  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"
  • dilap 5y ago
    For me, having it be a real commit is nicer -- can switch between branches, push if I'm switching computers, look at history, &c.
• klysm 5y ago
  Might be a useful workflow for you to use fixup commits to rebase automatically helps you out
  • Vinnl 5y ago
    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.
• mbarneyme 5y ago
  Do you have those commands handy by chance? :D
  • jasonpeacock 5y ago
    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.
    • glenjamin 5y ago
      You can use `-v` on the add to see what it’s doing instead of the extra status
  • dilap 5y ago
    Sure thing https://gist.github.com/erinok/0247c134a57acdb2e2daafdf1d77a494 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)
• merightnow 5y ago
  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.
  • genuine_smiles 5y ago
    I keep a draft PR open to keep track of this. Not has nice as vs-codes diff tool though.
    • ianjsikes 5y ago
      You can still use VS Code's diff if you have the GitHub Pull Requests extension: https://marketplace.visualstudio.com/items?itemName=GitHub.vscode-pull-request-github https://marketplace.visualstudio.com/items?itemName=GitHub.v...
      • Larrikin 5y ago
        Anything that would allow a similar workflow in JetBrains IDEs?
  • chayleaf 5y ago
    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)
• Ransom_ 5y ago
  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 https://github.com/uptech/git-ps
  • brynjolf 5y ago
    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?
• bastardoperator 5y ago
  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.
  • whoomp12342 5y ago
    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.
    • Quekid5 5y ago
      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.)
      • dijonman2 5y ago
        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.
        • Quekid5 5y ago
          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.
• buscoquadnary 5y ago
  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.
• matsemann 5y ago
  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".
  • pjerem 5y ago
    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
  • sa46 5y ago
    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.
  • TimTheTinker 5y ago
    I just checked, it looks like there is a VSCode plugin that does this: https://marketplace.visualstudio.com/items?itemName=xyz.local-history https://marketplace.visualstudio.com/items?itemName=xyz.loca... Repo here: https://github.com/zabel-xyz/local-history https://github.com/zabel-xyz/local-history Doesn't appear to mark checkpoints with metadata, though (test failed/passed, etc.).
• barbazoo 5y ago
  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.
  • mlyle 5y ago
    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.
• pizza 5y ago
  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
• tomrod 5y ago
  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.
  • texuf 5y ago
    probably just an alias in .bash_profile, here's the first thing I found in google: https://www.moncefbelyamani.com/create-aliases-in-bash-profile-to-assign-shortcuts-for-common-terminal-commands/ https://www.moncefbelyamani.com/create-aliases-in-bash-profi...
  • dilap 5y ago
    Yup, check out my comment here: https://news.ycombinator.com/item?id=29786798 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.)
• gen220 5y ago
  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!
  • mlyle 5y ago
    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.
    • gen220 5y ago
      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.
• kjeetgill 5y ago
  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.
• rubyist5eva 5y ago
  You can do this already with git natively. https://thoughtbot.com/blog/autosquashing-git-commits https://thoughtbot.com/blog/autosquashing-git-commits
• nicois 5y ago
  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/e7f90dce7031993afd4677dfb7e84284 https://gist.github.com/nicois/e7f90dce7031993afd4677dfb7e84...
• fivea 5y ago
  > 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.
  • int_19h 5y ago
    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.
    • fivea 5y ago
      > 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.
      • int_19h 5y ago
        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.
• meribold 5y ago
  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.