4 ms·

This is all well and good, but if you check in intentionally broken code, or if you fail to check in your code because it is intentionally broken, it will drive

This is all well and good, but if you check in intentionally broken code, or if you fail to check in your code because it is intentionally broken, it will drive me bananas, and I will look for you, and I will find you.

krupan 13y ago
Have you heard of distributed revision control? Local check-ins are awesome.
- pipeep 13y ago
  Unfortunately, that doesn't keep some idiots from pushing broken code to `origin master`.
  - kodablah 13y ago
    Why can they do so on a mature project? Why can they not only push to their branch, have the repo have commit/push hooks for fast linting, have CI builds for each commit, and only merge into master when comfortable (e.g. after QA)? And if it's a fairly new project and they're working in master directly, what's the harm of broken code?
  - jamesadney 13y ago
    Even non-idiots make mistakes. Use the pre-push hook that comes with your repo: https://github.com/git/git/blob/master/templates/hooks--pre-push.sample https://github.com/git/git/blob/master/templates/hooks--pre-... Then, just mark your commits with WIP.
RegW 13y ago
By "break", I assume he toilet or coffee. So I assume he means code that he hasn't checked in yet, but might do when he gets back if he can't remember what was doing and it compiles. Personally, I like to check in broken code late on that Friday evening before I take 2 weeks holiday. Unfortunately, these days with these new fangled source control systems you can't check it out again and keep it locked while you are away.
pdenya 13y ago
It's no trouble at all to work on a personal branch and merge it back in once it's fixed/complete. Especially if you're planning on doing it and are using a tool like git flow.
- CUViper 13y ago
  If you leave broken commits in the history, you'll make it very hard to use tools like "git bisect". You can "skip" broken commits, but that should be an occasional exception. It doesn't matter if that was on a personal branch either, because once you merge it's all part of the same graph of commits. I have no problem with broken commits locally, but I don't want to see those in a public tree. Merge or rebase with squashing, please.
  - narsil 13y ago
    A rebase in the personal branch that squashes the broken commit into the ones that fixed it would remove any traces of broken code in the master branch.
nickbauman 13y ago
I never check it in in this state. Checkins are 100% working and passing all tests for me.
SideburnsOfDoom 13y ago
> if you check in intentionally broken code ... Agreed, but that's not what you should do. Many times I have finished the day with a working commit and push, then I add a compiler-error "todo ..." line to the code locally so that it's clear where I have to resume tomorrow.

krupan 13y ago

Have you heard of distributed revision control? Local check-ins are awesome.

pipeep 13y ago
Unfortunately, that doesn't keep some idiots from pushing broken code to `origin master`.
- kodablah 13y ago
  Why can they do so on a mature project? Why can they not only push to their branch, have the repo have commit/push hooks for fast linting, have CI builds for each commit, and only merge into master when comfortable (e.g. after QA)? And if it's a fairly new project and they're working in master directly, what's the harm of broken code?
- jamesadney 13y ago
  Even non-idiots make mistakes. Use the pre-push hook that comes with your repo: https://github.com/git/git/blob/master/templates/hooks--pre-push.sample https://github.com/git/git/blob/master/templates/hooks--pre-... Then, just mark your commits with WIP.

RegW 13y ago

By "break", I assume he toilet or coffee. So I assume he means code that he hasn't checked in yet, but might do when he gets back if he can't remember what was doing and it compiles. Personally, I like to check in broken code late on that Friday evening before I take 2 weeks holiday. Unfortunately, these days with these new fangled source control systems you can't check it out again and keep it locked while you are away.

pdenya 13y ago

It's no trouble at all to work on a personal branch and merge it back in once it's fixed/complete. Especially if you're planning on doing it and are using a tool like git flow.

CUViper 13y ago
If you leave broken commits in the history, you'll make it very hard to use tools like "git bisect". You can "skip" broken commits, but that should be an occasional exception. It doesn't matter if that was on a personal branch either, because once you merge it's all part of the same graph of commits. I have no problem with broken commits locally, but I don't want to see those in a public tree. Merge or rebase with squashing, please.
- narsil 13y ago
  A rebase in the personal branch that squashes the broken commit into the ones that fixed it would remove any traces of broken code in the master branch.

nickbauman 13y ago

I never check it in in this state. Checkins are 100% working and passing all tests for me.

SideburnsOfDoom 13y ago

> if you check in intentionally broken code ... Agreed, but that's not what you should do. Many times I have finished the day with a working commit and push, then I add a compiler-error "todo ..." line to the code locally so that it's clear where I have to resume tomorrow.