Avery Pennarun <apenwarr@xxxxxxxxx> writes: > This is a big difference from how centralized VCSs work: there, a > commit is a major operation that you're afraid to do in case you make > someone else mad. In git, commits are cheap, you just need to be > careful about pushing. I second this. "commit" is indeed a bad name in decentralized VCSs. There's no commitment from the developer, you don't commit to swear the code is good, but you commit just to record a set of changes, and attach a descriptive message to it. In Git, a commit takes usually a fraction of a second, and can be modified later easily until it's pushed. 'git commit --amend' will allow you to change either the changes or the message associated to a commit. 'git reset HEAD^' will just undo the commit, turning your commited changes into uncommited ones. 'git rebase --interactive' will allow you another bunch of cool things. So, keeping your changes uncommited has very few advantage, and indeed has one big drawback: uncommited changes have no descriptive message associated, so if you leave a branch for some time, it makes it more difficult for you to remember what you were doing on it when you switch back to it: git checkout -b topic-branch # edit foo.bar git checkout master # hack git commit # go on holiday # come back git checkout topic-branch git status # err, what is this all about? OTOH: git checkout -b topic-branch # edit foo.bar git commit -m "started feature foo, but bar is still to be done" git checkout master # hack git commit # go on holiday # come back git checkout topic-branch git show # Ah, I remember! Actually, all the VCSs I know about (Mercurial, Bazaar, Subversion, and IIRC GNU Arch) deal with this the way Git does. Hey! there must be a reason ;-). -- Matthieu -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html