5 ms·

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

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 16y 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?

masklinn 16y 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?