2 ms·
As opposed to there probably aren't really good reasons. Doing it in addition to source control seems like something everyone should do though. The way people
by robryan 13y ago
As opposed to there probably aren't really good reasons.
Doing it in addition to source control seems like something everyone should do though.
The way people generally use source control isn't to push every single line added or changed to a remote copy of the repo as soon as it is done. A commit is more tied to completing a task, you need something else to cover you for loss for smaller amounts of code than that if your computer dies.
- dhimes 13y agoThis is apparently the subject of some debate. More specifically to me, it depends on what branch I'm on. If I'm on dev, I have no problem with big commits. (For features I'll often set a bookmark [hg]- maybe even clone and work from the clone if it's risky). But if I'm on test or hotfixing on stable, I use very small commits so that I can easily graft (backport) back to dev. But at the very least I have more than one commit message like -FIX blah blah commit so can get from <name of other machine>