Hi, On Thu, 19 Apr 2007, Jakub Narebski wrote: > Steven Grimm wrote: > > > One can argue about whether allowing partial commits like that is a > > good idea, but it's just not true that svn forces you to always update > > before you commit, and if you're pushing into a branch that other > > people are also updating, the ability to commit files that didn't > > change upstream means it is actually *less* insistent on > > update-then-commit than git is (if you take "commit" to mean > > "commit-and-push" on the git side as was suggested in the message I > > replied to originally.) > > > > Unless, of course, I'm misinterpreting you here. > > I just think the commit _then_ merge (or commit-then-update) workflow is > much, much better than update-then-commit one. Let me pick up the ball here. Once you did your share of conflicting merges, you _will_ realize how much better it is to merge when you are at a relatively stable state, i.e. you can test things (if only to make sure that the merge did not introduce strange side effects). And guess what, at such a stage I would commit anyway. It is so much easier to resolve conflicts if you can look at both sides, and can actually go to both sides to test things out, or even just generate the diff to one side. This is just not possible with a dirty merge. Exactly because you knowingly lost the current state, you cannot do diffs with it. Needless to say (but I do it nevertheless, since I am in a chatty mood), I _never_ can be seen doing the 4-command equivalent of `svn up`. I only pull when I have a clean state. (Note: this also leads to a more structured way of working, which does prevent errors.) Ciao, Dscho - 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