6 ms·

I gave a skim and didn't find this 11. Never commit revisions which can't be built. (In the exceptional cases, always state in the commit message that the code

by b0sk 15y ago

I gave a skim and didn't find this 11. Never commit revisions which can't be built. (In the exceptional cases, always state in the commit message that the code doesn't build.)

ZeroMinx 15y ago
I disagree. Get your code updates in there when leaving for the evening/weekend. But, of course, you'll do it in your own project branch that doesn't affect other people.
- joeyespo 15y ago
  Even then, I usually comment out partial code then slap on a TODO. And where it makes sense, I'll also add in a "throw NotImplementedException" or some equivalent, so it's explicit that the code isn't expected behavior when executed. It's usually not much effort to do this. Especially when you plan ahead while you write. There's always repercussions to checking in unbuildable code. Suddenly, nobody else can contribute or pull from that branch without first fixing your bad code, for one. What's worse is when they think it's a mistake and do tweak your code. You'll have to backtrack then, adding noise to the file's history. Another is when you need to roll back. If you allow broken commits, there's always a change of hitting a broken version. In times of emergency, you really don’t want to be bogged down by unbuildable code.
tomjen3 15y ago
Nah that isn't an issue anymore - just don't merge it with the main trunk.
bnegreve 15y ago
This. is wrong. One should be able to commit every little meaningful change he has made, with a equally meaningful commit message. If you wait until everything works you'll end with huge meaningless conflicting commits. Of course it is quite annoying if you use a centralized SCM since everything you commit becomes public. Well this is actually why you should not use centralized SCM.
- masklinn 15y ago
  > One should be able to commit every little meaningful change he has made, with a equally meaningful commit message. If your commit is broken, it's not meaningful, it's just broken. > If you wait until everything works you'll end with huge meaningless conflicting commits. Reading comprehension, please. b0sk talked about commits which can not be built. It's a very clear and simple requirement and it definitely does not mean is not feature-complete. > Of course it is quite annoying if you use a centralized SCM since everything you commit becomes public. Well this is actually why you should not use centralized SCM. There really is no relation, and a DVCS will not save you when an axe-murderer with a short temper tries to bisect a bug, and you break his bisection because your commits made the whole project un-buildable.
  - gcr 15y ago
    Let's try this again. Speaking as a git user, my workflow is a little different. > If your commit is broken, it's not meaningful, it's just broken. Sometimes I make broken commits just to have something for the written record. Sometimes I rebase them away. Sometimes I ask friends to pull from a broken commit (gasp!) when I need their help to fix my bug. Often times I 'git commit --amend' to fix broken commits before I push. In any case, there's no reason to artificially hide these mistakes as long as the result works. > There really is no relation, and a DVCS will not save you when an axe-murderer with a short temper tries to bisect a bug, and you break his bisection because your commits made the whole project un-buildable. Git allows you to automatically skip untestable commits. See http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html#_bisect_run http://www.kernel.org/pub/software/scm/git/docs/git-bisect.h... In my workflow, I usually use a 'master' branch and 'topic' branches. The master must always build, as you say. Topic branches don't -- they're experimental by definition. When a topic is ready to go, we rebase and clean up the commits. This way, we get a traceable, ever-buildable source tree from master and experimental branches when we want them. Problem?
InclinedPlane 15y ago
With modern technologies this is definitely a no-no. With DVCS you can create your own branch and push it to other systems super easily, so there's little excuse for checking in broken code to a shared branch. Also, with a lot of newer VCSes there's often a feature to "shelve" a changeset to a central DB without committing it. Not to mention that breaking the build for more than a few minutes raises some serious red flags about the way you're working.
- ekidd 15y ago
  I agree that breaking the build is normally a very bad idea. I've gone after friends with Nerf weapons for doing this. :-) But there are a few cases where it's a necessary evil. For example, when upgrading a large Rails application from Rails 2.3 to 3.0, you're likely to make hundreds of small changes before everything works again. In this case, I create a new branch, prepend "BROKEN:" to each commit message, and record the number of unit tests that are currently passing. Once all the tests are fixed, I hand-test, add new tests for any regressions that weren't caught by the automatic tests, and merge back to the main development branch.
  - tuxychandru 15y ago
    Why not squash all the broken commits together before pushing to the central repository (assuming you use a DVCS)?
    - josegonzalez 15y ago
      Because rewriting history is a no-no.
      - jimktrains2 15y ago
        :: raises hand :: Only if no one else ever saw that part of history, right? :: shaky eyes ::
pnathan 15y ago
Baloney. That's what branches are for. That's the whole point of committing often. A disciplined approach to branching will deal with the problem.

by b0sk 15y ago

I gave a skim and didn't find this 11. Never commit revisions which can't be built. (In the exceptional cases, always state in the commit message that the code doesn't build.)

ZeroMinx 15y ago

I disagree. Get your code updates in there when leaving for the evening/weekend. But, of course, you'll do it in your own project branch that doesn't affect other people.

joeyespo 15y ago
Even then, I usually comment out partial code then slap on a TODO. And where it makes sense, I'll also add in a "throw NotImplementedException" or some equivalent, so it's explicit that the code isn't expected behavior when executed. It's usually not much effort to do this. Especially when you plan ahead while you write. There's always repercussions to checking in unbuildable code. Suddenly, nobody else can contribute or pull from that branch without first fixing your bad code, for one. What's worse is when they think it's a mistake and do tweak your code. You'll have to backtrack then, adding noise to the file's history. Another is when you need to roll back. If you allow broken commits, there's always a change of hitting a broken version. In times of emergency, you really don’t want to be bogged down by unbuildable code.

tomjen3 15y ago

Nah that isn't an issue anymore - just don't merge it with the main trunk.

bnegreve 15y ago

This. is wrong. One should be able to commit every little meaningful change he has made, with a equally meaningful commit message. If you wait until everything works you'll end with huge meaningless conflicting commits. Of course it is quite annoying if you use a centralized SCM since everything you commit becomes public. Well this is actually why you should not use centralized SCM.

masklinn 15y ago
> One should be able to commit every little meaningful change he has made, with a equally meaningful commit message. If your commit is broken, it's not meaningful, it's just broken. > If you wait until everything works you'll end with huge meaningless conflicting commits. Reading comprehension, please. b0sk talked about commits which can not be built. It's a very clear and simple requirement and it definitely does not mean is not feature-complete. > Of course it is quite annoying if you use a centralized SCM since everything you commit becomes public. Well this is actually why you should not use centralized SCM. There really is no relation, and a DVCS will not save you when an axe-murderer with a short temper tries to bisect a bug, and you break his bisection because your commits made the whole project un-buildable.
- gcr 15y ago
  Let's try this again. Speaking as a git user, my workflow is a little different. > If your commit is broken, it's not meaningful, it's just broken. Sometimes I make broken commits just to have something for the written record. Sometimes I rebase them away. Sometimes I ask friends to pull from a broken commit (gasp!) when I need their help to fix my bug. Often times I 'git commit --amend' to fix broken commits before I push. In any case, there's no reason to artificially hide these mistakes as long as the result works. > There really is no relation, and a DVCS will not save you when an axe-murderer with a short temper tries to bisect a bug, and you break his bisection because your commits made the whole project un-buildable. Git allows you to automatically skip untestable commits. See http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html#_bisect_run http://www.kernel.org/pub/software/scm/git/docs/git-bisect.h... In my workflow, I usually use a 'master' branch and 'topic' branches. The master must always build, as you say. Topic branches don't -- they're experimental by definition. When a topic is ready to go, we rebase and clean up the commits. This way, we get a traceable, ever-buildable source tree from master and experimental branches when we want them. Problem?

InclinedPlane 15y ago

With modern technologies this is definitely a no-no. With DVCS you can create your own branch and push it to other systems super easily, so there's little excuse for checking in broken code to a shared branch. Also, with a lot of newer VCSes there's often a feature to "shelve" a changeset to a central DB without committing it. Not to mention that breaking the build for more than a few minutes raises some serious red flags about the way you're working.

ekidd 15y ago
I agree that breaking the build is normally a very bad idea. I've gone after friends with Nerf weapons for doing this. :-) But there are a few cases where it's a necessary evil. For example, when upgrading a large Rails application from Rails 2.3 to 3.0, you're likely to make hundreds of small changes before everything works again. In this case, I create a new branch, prepend "BROKEN:" to each commit message, and record the number of unit tests that are currently passing. Once all the tests are fixed, I hand-test, add new tests for any regressions that weren't caught by the automatic tests, and merge back to the main development branch.
- tuxychandru 15y ago
  Why not squash all the broken commits together before pushing to the central repository (assuming you use a DVCS)?
  - josegonzalez 15y ago
    Because rewriting history is a no-no.
    - jimktrains2 15y ago
      :: raises hand :: Only if no one else ever saw that part of history, right? :: shaky eyes ::

pnathan 15y ago

Baloney. That's what branches are for. That's the whole point of committing often. A disciplined approach to branching will deal with the problem.