3 ms·

Git's incremental commits may be a great idea in theory, but in practice, it allows you--even forces you, if you run in any mode except "git add ."--to make com

by gecko 17y ago

Git's incremental commits may be a great idea in theory, but in practice, it allows you--even forces you, if you run in any mode except "git add ."--to make commits you've never actually tested. I'd rather have a cluttered history that built at any given point than a clean one that didn't.

tow21 17y ago
It's the other way around. Partial commits terrify me in theory; in practice it's really easy to work out which lines you want to commit and which lines you don't, and having a clean history is really really nice. And since you've got both "git commit --amend" and "git rebase -i" to hand, it's trivial to later on fix up any mistakes you do make. Honestly, having a clean history is an enormous win - it far outweighs the minor cost of making the odd wrong but easily-correctable-after-the-fact commit.
- gecko 17y ago
  You can have both, you know: you use git stash/Mercurial attic to shelve the parts of the change you don't want, test the result, commit, then reapply what you stashed. You get a clean history, and you can easily verify your source code works. This solution notably does not involve explicitly exposing the dirstate to the user.
etal 17y ago
It's not so bad as long as you don't push any untested changes. If I do something freaky with the index, I usually stash the leftovers and test the last commit. Like this: git add -i git commit git stash ./some_tests # ...shoot, forgot something git add . # whatever I forgot git commit --amend ./some_tests # now we're good git stash apply git stash clear git push On the hg side, you can use mq and record to get yourself in and out of the same kind of trouble, as someone else mentioned. I think these are essential but dangerous features that any good DVCS should have. A better safety mechanism (than deleting the feature) is a pre-push hook that runs the test suite on every commit since the remote head. Not everyone needs that level of strictness, though.
jrockway 17y ago
I feel the opposite way. I often see hunks like: sub foo { + warn "made it here"; actual code; } This stuff, I never want to commit. Sure, I haven't tested the code without it, but I'm sure it works. Subversion-style committing sucks hard; worst idea ever. (And besides, svn still lets you do this; svn commit one-file. Untested tree committed, with no possibility of ever backing out the change. Not good.)

by gecko 17y ago

tow21 17y ago

It's the other way around. Partial commits terrify me in theory; in practice it's really easy to work out which lines you want to commit and which lines you don't, and having a clean history is really really nice. And since you've got both "git commit --amend" and "git rebase -i" to hand, it's trivial to later on fix up any mistakes you do make. Honestly, having a clean history is an enormous win - it far outweighs the minor cost of making the odd wrong but easily-correctable-after-the-fact commit.

gecko 17y ago
You can have both, you know: you use git stash/Mercurial attic to shelve the parts of the change you don't want, test the result, commit, then reapply what you stashed. You get a clean history, and you can easily verify your source code works. This solution notably does not involve explicitly exposing the dirstate to the user.

etal 17y ago

It's not so bad as long as you don't push any untested changes. If I do something freaky with the index, I usually stash the leftovers and test the last commit. Like this: git add -i git commit git stash ./some_tests # ...shoot, forgot something git add . # whatever I forgot git commit --amend ./some_tests # now we're good git stash apply git stash clear git push On the hg side, you can use mq and record to get yourself in and out of the same kind of trouble, as someone else mentioned. I think these are essential but dangerous features that any good DVCS should have. A better safety mechanism (than deleting the feature) is a pre-push hook that runs the test suite on every commit since the remote head. Not everyone needs that level of strictness, though.

jrockway 17y ago

I feel the opposite way. I often see hunks like: sub foo { + warn "made it here"; actual code; } This stuff, I never want to commit. Sure, I haven't tested the code without it, but I'm sure it works. Subversion-style committing sucks hard; worst idea ever. (And besides, svn still lets you do this; svn commit one-file. Untested tree committed, with no possibility of ever backing out the change. Not good.)