8 ms·

Committing code should not be a glorified Ctrl/Cmd+S. With few exceptions each commit should be an isolated unit of work. Also, this floating to the top of HN i

by remon 12y ago

Committing code should not be a glorified Ctrl/Cmd+S. With few exceptions each commit should be an isolated unit of work. Also, this floating to the top of HN is a bit of a mystery to me.

philjackson 12y ago
You're right. I cringe a bit when I hear people say "I've not committed for a while, I'll do it now". Ok, and if I need to revert any of it, I'll have to do it hunk by hunk?
- masukomi 12y ago
  committing after some random number of saves or lines seems silly yes. but i see no reason to not commit whenever you come to a stopping point. even if that stopping point is as arbitrary as the time to go home. I've never seen a case where someone would revert hunk by hunk. You can just revert to the last stopping point, if you need to, or as most people do just keep editing the file, hitting undo, editing, hitting undo... etc until you have another stopping point. commit. repeat. when you're all done you clean up the commits with rebase and voilla. life is good.
  - philjackson 12y ago
    I'm talking more about the situation a fellow team member has to revert something that Frank wrote that's dropped production at 3am. Trawling through commits that contain half of two small features because he commits based on home time and coffee breaks in an emergency sounds terrible.
    - klibertp 12y ago
      He will just revert a merge. Because you branch and merge for anything less trivial than one-line comment, right?
- akerl_ 12y ago
  That's exactly what the idea is here. If you commit very incrementally during development cycles, you're more likely to have a singular commit to revert. Then before you push upstream, you rebase down your commits into full feature chunks.
rmsaksida 12y ago
There's nothing wrong with committing often, but pushing too often should not be encouraged. If you commit a lot, you should probably rebase before pushing.
- Touche 12y ago
  > There's nothing wrong with committing often, but pushing too often should not be encouraged. Pushing often is just as import. Computers do fail.
  - Dewie 12y ago
    If the concern is the computer failing, you should do backups. And it's probably simpler to use automated backups than using git push as a backup mechanism.
    - maguirre 12y ago
      Automated backups are useful. However how often can you backup? If you are hacking/experimenting backing up after every change seems too resource intensive
      - Dewie 12y ago
        I back up every 10 minutes. So I lose 10 minutes if I screw something up, which is acceptable to me. I guess I could back up every 5 minutes, and I don't think that would be a problem.
    - Touche 12y ago
      Adding another thing I have to keep track of and maintain is not simpler than 1 command that is pure muscle reflex.
      - Dewie 12y ago
        Once you have automated backup set up, how much work is it to maintain? If you keep your code in a few areas/directories (like for example /home/workspace), it seems like a set-it-and-forget-it thing. PS: how is a command that demands that you write a commit message really just 'muscle memory'?
robmccoll 12y ago
This is true, but it's often too easy to wait and commit an entire feature or other larger change that is made up of 3 or 4 reasonably well-isolated smaller changes that might be better independent commits especially for bisection purposes.
- agumonkey 12y ago
  That's, to me, the exact blind spot of versionning as it is, we need some 'theory' on how to size/modularize commits to avoid micro-commits explosion but also spaghetti patches. More than that it relates to how you resolve, design, test a system.
Touche 12y ago
You can commit as many times as you want in a feature branch and simply squash them down to one when you are finished.
- wldlyinaccurate 12y ago
  So much this. In my experience it is extremely useful to have a bunch of "Unfinished; WIP" commits that I can look through to figure out what I was thinking yesterday when I started writing code. When I'm ready for other people to pull my commits, I'll rebase them into more meaningful commits (or often just one single commit).
- cjantz 12y ago
  How and when to comment should be a decision made by the contributors working on the feature, but squashing is something I always disallow for any team I work with just to keep the history and be able to follow the programmer when chasing down a bug. My biggest concern here is, that you have to force push because of you rewrite the git history. That way you are most likely going to loose data. If you need WIP commits to switch branches use the stash instead. You won't overload your history that way in a cleaner way.
  - madeofpalk 12y ago
    > My biggest concern here is, that you have to force push because of you rewrite the git history. That way you are most likely going to loose data. Not entirely true. If you only squash when you merge the branch in, there's no need for the force-push. Rebasing into the already pushed history should be flat out banned without question within teams, and force-push be disabled within configs. It's only in exceptional circumstances where you would actually need to do these.
    - cjantz 12y ago
      Exactly! But why do you need to squash while merging? The concept of merge tells that a branch is merged into the history by adding a merge commit. This commit reflects all differences. It's done automatically if possible - you need to resolve conflicts if it's not. Correct me if I'm wrong but in my understanding a merge does nothing else than create a commit which is like a squashed representation.
michaelmior 12y ago
I tend to commit as I get part of a "unit of work" done that I'm happy with. Then I just amend that commit as I go until I'm done. That way if I mess something up before I'm finished, it's easy for me to go back to a state where things were in better shape.
phn 12y ago
If you're on a feature branch, you can probably commit often, and push often (effectively backing up your work), then, the isolated unit of work is done on a single commit (non-FF) when merging with the main branch (this is the one you search for when you want to revert something or find the culprit for something). This allows having "best of both worlds", I think. EDIT: Take a look at the feature branches on the git flow model: http://nvie.com/posts/a-successful-git-branching-model/ http://nvie.com/posts/a-successful-git-branching-model/
moomin 12y ago
Actually, a glorified save is exactly what a git commit is. I literally have a command that (haskell) compiles and commits everything if it compiled. I sort it out into sensible commits later.
akavel 12y ago
You can really have two "species" of commits: One of them is the "published, shared" kind; for this one, I can agree with you, that they should be self-contained and complete, especially when there many devs on the project, and/or you'd like to be able to use bisect. The second kind, and for me actually a very important one, is more of a "local backup, dirty hacking" one. Those shouldn't probably be published (unless a private/one-guy repo), but allow for easy hacking, developing, testing, experimenting. The "commit often, whatever you have, however broken or non-ideal" approach provides safe lightweight backup, and allows for easy switching between various paths/approaches. Now, after you design stabilizes, dust settles down, and you are completing the work, you can (and probably should) eventually either just squash everything into one final feature commit (the end result will be indistinguishable to what you'd deliver if not committing in the meantime), or remodel the intermediary commits to whatever ideal shape you like them to have retroactively (with "git rebase -i", including patch editing etc.) Knowing the benefits of this approach, I don't understand why anyone would want to reject it. edit: Also, with many small, dirty commits, it's sometimes possible to fairly quickly do stuff like carving out some subfeature into a separate branch (with judicious use of rebases, cherrypicking and some occasional small edits). Or, remove/revert commits marked earlier as DEBUG. Seems useful to me, as a means to somewhat speed up such operations and decrease the possibility of manual error at the same time.
- vertex-four 12y ago
  Shouldn't we then have a tool which separates out "published, shared" commits from WIP commits, if they're different "types"?
  - blablabla123 12y ago
    It's more of a workflow thing. When working on a difficult feature, or rather difficult ticket, that cannot reasonably split into 2, it makes sense to work on a separate feature branch. This branch is just for yourself and can be polluted with dirty commits. Once your done, your can git rebase the thing into one, beautiful commit.
    - 12y ago
chatmasta 12y ago
I was also surprised to see it at the top of HN. I would attribute it to 1) reflexive meme upvoting, and 2) a nice discussion on when to commit.
- TeMPOraL 12y ago
  I think mostly 2). Many people, myself included, often upvote stories for the discussion in the comments here.
aaron695 12y ago
> Also, this floating to the top of HN is a bit of a mystery to me. Then you should take the time to think about why. Either you are not understanding the issue or not understanding the current view by most people on the issue. Either way you're not at industry standard.
- sfk 12y ago
  s/industry/echo chamber/
Trufa 12y ago
I personally prefer the workflow of writing all the necessary code (not an arbitrary number) and then patch committing. You get the best of two worlds, atomic commits and enough code for your commits to make sense in context.
- Anderkent 12y ago
  This is the same as doing WIP commits then re-building the history when done, except you can't move your WIP between machines easily, can't leave yourself notes when wrapping up for the day, etc etc
prezjordan 12y ago
> Committing code should not be a glorified Ctrl/Cmd+S. What? Of course it is. Commit as many times as you want, branch when testing out a segment of code, do all the fancy things you need to do - then clean it all up when you're done.
- astrobe_ 12y ago
  You could say "What? Of course one can walk with hands, I haven't bought a pair of shoes for years." Just because it "works for you" doesn't mean it's sensible or efficient.
  - prezjordan 12y ago
    You're framing my train of thought as unnecessary or atypical and that's dishonest. There is no downside to having more granular revision history. It's important to recognize that, not necessary to follow, though.
    - Daviey 12y ago
      Rest assured, anyone not committing (or stashing) often and squashing down is doing it wrong.
Nursie 12y ago
Nonsense. Commit to your branch as often as you want for backups, for milestones, because it's the end of the day, whatever. The isolated unit of work can be pulled/pushed to the shared stream when it's more complete.
- silverbax88 12y ago
  How big of a team and how big of a codebase? Often massive amounts of commits during development wreak havoc on interconnected projects. At least in Git, not so much in TFS. Mercurial kind of splits the gap.
  - Nursie 12y ago
    I've worked with git in small teams (~5) and with other systems like clearcase in larger teams (20+, ~100 if you count sister teams). So long as everyone is working on their own branches and pushing/pulling to a shared stream when features are complete, and that pushed to a release stream when releases are to be prepared.... I don't see why folks couldn't comm8t every 5 minutes if they wanted. It's more interesting to discuss the strategy for moving code from personal branches to development, and dev to release.
    - JoeAltmaier 12y ago
      Even more complicated: moving code from branch to branch. To share needed support, or bug fixes, or test interoperability. If you can push to the shared stream and the others pull it up to their branch, cool. But with interoperability testing of incomplete features that's not ok.
taybin 12y ago
Because it's funny. Don't be a grumpy programmer.
deleted 12y ago
[deleted]
eloisant 12y ago
1. You can commit as a way to record a "working state" to go back if you break too much stuff, and rebase to squash it before pushing if necessary. 2. If your commit is too big, you should probably rethink it in smaller steps

by remon 12y ago

Committing code should not be a glorified Ctrl/Cmd+S. With few exceptions each commit should be an isolated unit of work. Also, this floating to the top of HN is a bit of a mystery to me.

philjackson 12y ago

You're right. I cringe a bit when I hear people say "I've not committed for a while, I'll do it now". Ok, and if I need to revert any of it, I'll have to do it hunk by hunk?

masukomi 12y ago
committing after some random number of saves or lines seems silly yes. but i see no reason to not commit whenever you come to a stopping point. even if that stopping point is as arbitrary as the time to go home. I've never seen a case where someone would revert hunk by hunk. You can just revert to the last stopping point, if you need to, or as most people do just keep editing the file, hitting undo, editing, hitting undo... etc until you have another stopping point. commit. repeat. when you're all done you clean up the commits with rebase and voilla. life is good.
- philjackson 12y ago
  I'm talking more about the situation a fellow team member has to revert something that Frank wrote that's dropped production at 3am. Trawling through commits that contain half of two small features because he commits based on home time and coffee breaks in an emergency sounds terrible.
  - klibertp 12y ago
    He will just revert a merge. Because you branch and merge for anything less trivial than one-line comment, right?
akerl_ 12y ago
That's exactly what the idea is here. If you commit very incrementally during development cycles, you're more likely to have a singular commit to revert. Then before you push upstream, you rebase down your commits into full feature chunks.

rmsaksida 12y ago

There's nothing wrong with committing often, but pushing too often should not be encouraged. If you commit a lot, you should probably rebase before pushing.

Touche 12y ago
> There's nothing wrong with committing often, but pushing too often should not be encouraged. Pushing often is just as import. Computers do fail.
- Dewie 12y ago
  If the concern is the computer failing, you should do backups. And it's probably simpler to use automated backups than using git push as a backup mechanism.
  - maguirre 12y ago
    Automated backups are useful. However how often can you backup? If you are hacking/experimenting backing up after every change seems too resource intensive
    - Dewie 12y ago
      I back up every 10 minutes. So I lose 10 minutes if I screw something up, which is acceptable to me. I guess I could back up every 5 minutes, and I don't think that would be a problem.
  - Touche 12y ago
    Adding another thing I have to keep track of and maintain is not simpler than 1 command that is pure muscle reflex.
    - Dewie 12y ago
      Once you have automated backup set up, how much work is it to maintain? If you keep your code in a few areas/directories (like for example /home/workspace), it seems like a set-it-and-forget-it thing. PS: how is a command that demands that you write a commit message really just 'muscle memory'?

robmccoll 12y ago

This is true, but it's often too easy to wait and commit an entire feature or other larger change that is made up of 3 or 4 reasonably well-isolated smaller changes that might be better independent commits especially for bisection purposes.

agumonkey 12y ago
That's, to me, the exact blind spot of versionning as it is, we need some 'theory' on how to size/modularize commits to avoid micro-commits explosion but also spaghetti patches. More than that it relates to how you resolve, design, test a system.

Touche 12y ago

You can commit as many times as you want in a feature branch and simply squash them down to one when you are finished.

wldlyinaccurate 12y ago
So much this. In my experience it is extremely useful to have a bunch of "Unfinished; WIP" commits that I can look through to figure out what I was thinking yesterday when I started writing code. When I'm ready for other people to pull my commits, I'll rebase them into more meaningful commits (or often just one single commit).
cjantz 12y ago
How and when to comment should be a decision made by the contributors working on the feature, but squashing is something I always disallow for any team I work with just to keep the history and be able to follow the programmer when chasing down a bug. My biggest concern here is, that you have to force push because of you rewrite the git history. That way you are most likely going to loose data. If you need WIP commits to switch branches use the stash instead. You won't overload your history that way in a cleaner way.
- madeofpalk 12y ago
  > My biggest concern here is, that you have to force push because of you rewrite the git history. That way you are most likely going to loose data. Not entirely true. If you only squash when you merge the branch in, there's no need for the force-push. Rebasing into the already pushed history should be flat out banned without question within teams, and force-push be disabled within configs. It's only in exceptional circumstances where you would actually need to do these.
  - cjantz 12y ago
    Exactly! But why do you need to squash while merging? The concept of merge tells that a branch is merged into the history by adding a merge commit. This commit reflects all differences. It's done automatically if possible - you need to resolve conflicts if it's not. Correct me if I'm wrong but in my understanding a merge does nothing else than create a commit which is like a squashed representation.

michaelmior 12y ago

I tend to commit as I get part of a "unit of work" done that I'm happy with. Then I just amend that commit as I go until I'm done. That way if I mess something up before I'm finished, it's easy for me to go back to a state where things were in better shape.

phn 12y ago

If you're on a feature branch, you can probably commit often, and push often (effectively backing up your work), then, the isolated unit of work is done on a single commit (non-FF) when merging with the main branch (this is the one you search for when you want to revert something or find the culprit for something). This allows having "best of both worlds", I think. EDIT: Take a look at the feature branches on the git flow model: http://nvie.com/posts/a-successful-git-branching-model/ http://nvie.com/posts/a-successful-git-branching-model/

moomin 12y ago

Actually, a glorified save is exactly what a git commit is. I literally have a command that (haskell) compiles and commits everything if it compiled. I sort it out into sensible commits later.

akavel 12y ago

You can really have two "species" of commits: One of them is the "published, shared" kind; for this one, I can agree with you, that they should be self-contained and complete, especially when there many devs on the project, and/or you'd like to be able to use bisect. The second kind, and for me actually a very important one, is more of a "local backup, dirty hacking" one. Those shouldn't probably be published (unless a private/one-guy repo), but allow for easy hacking, developing, testing, experimenting. The "commit often, whatever you have, however broken or non-ideal" approach provides safe lightweight backup, and allows for easy switching between various paths/approaches. Now, after you design stabilizes, dust settles down, and you are completing the work, you can (and probably should) eventually either just squash everything into one final feature commit (the end result will be indistinguishable to what you'd deliver if not committing in the meantime), or remodel the intermediary commits to whatever ideal shape you like them to have retroactively (with "git rebase -i", including patch editing etc.) Knowing the benefits of this approach, I don't understand why anyone would want to reject it. edit: Also, with many small, dirty commits, it's sometimes possible to fairly quickly do stuff like carving out some subfeature into a separate branch (with judicious use of rebases, cherrypicking and some occasional small edits). Or, remove/revert commits marked earlier as DEBUG. Seems useful to me, as a means to somewhat speed up such operations and decrease the possibility of manual error at the same time.

vertex-four 12y ago
Shouldn't we then have a tool which separates out "published, shared" commits from WIP commits, if they're different "types"?
- blablabla123 12y ago
  It's more of a workflow thing. When working on a difficult feature, or rather difficult ticket, that cannot reasonably split into 2, it makes sense to work on a separate feature branch. This branch is just for yourself and can be polluted with dirty commits. Once your done, your can git rebase the thing into one, beautiful commit.
  - 12y ago

chatmasta 12y ago

I was also surprised to see it at the top of HN. I would attribute it to 1) reflexive meme upvoting, and 2) a nice discussion on when to commit.

TeMPOraL 12y ago
I think mostly 2). Many people, myself included, often upvote stories for the discussion in the comments here.

aaron695 12y ago

> Also, this floating to the top of HN is a bit of a mystery to me. Then you should take the time to think about why. Either you are not understanding the issue or not understanding the current view by most people on the issue. Either way you're not at industry standard.

sfk 12y ago
s/industry/echo chamber/

Trufa 12y ago

I personally prefer the workflow of writing all the necessary code (not an arbitrary number) and then patch committing. You get the best of two worlds, atomic commits and enough code for your commits to make sense in context.

Anderkent 12y ago
This is the same as doing WIP commits then re-building the history when done, except you can't move your WIP between machines easily, can't leave yourself notes when wrapping up for the day, etc etc

prezjordan 12y ago

> Committing code should not be a glorified Ctrl/Cmd+S. What? Of course it is. Commit as many times as you want, branch when testing out a segment of code, do all the fancy things you need to do - then clean it all up when you're done.

astrobe_ 12y ago
You could say "What? Of course one can walk with hands, I haven't bought a pair of shoes for years." Just because it "works for you" doesn't mean it's sensible or efficient.
- prezjordan 12y ago
  You're framing my train of thought as unnecessary or atypical and that's dishonest. There is no downside to having more granular revision history. It's important to recognize that, not necessary to follow, though.
  - Daviey 12y ago
    Rest assured, anyone not committing (or stashing) often and squashing down is doing it wrong.

Nursie 12y ago

Nonsense. Commit to your branch as often as you want for backups, for milestones, because it's the end of the day, whatever. The isolated unit of work can be pulled/pushed to the shared stream when it's more complete.

silverbax88 12y ago
How big of a team and how big of a codebase? Often massive amounts of commits during development wreak havoc on interconnected projects. At least in Git, not so much in TFS. Mercurial kind of splits the gap.
- Nursie 12y ago
  I've worked with git in small teams (~5) and with other systems like clearcase in larger teams (20+, ~100 if you count sister teams). So long as everyone is working on their own branches and pushing/pulling to a shared stream when features are complete, and that pushed to a release stream when releases are to be prepared.... I don't see why folks couldn't comm8t every 5 minutes if they wanted. It's more interesting to discuss the strategy for moving code from personal branches to development, and dev to release.
  - JoeAltmaier 12y ago
    Even more complicated: moving code from branch to branch. To share needed support, or bug fixes, or test interoperability. If you can push to the shared stream and the others pull it up to their branch, cool. But with interoperability testing of incomplete features that's not ok.

taybin 12y ago

Because it's funny. Don't be a grumpy programmer.

deleted 12y ago

[deleted]

eloisant 12y ago

1. You can commit as a way to record a "working state" to go back if you break too much stuff, and rebase to squash it before pushing if necessary. 2. If your commit is too big, you should probably rethink it in smaller steps