From: Julian Phillips Date: Thu, 19 Apr 2007 08:57:10 GMT Subject: Re: GIT vs Other: Need argument Message-ID: In-Reply-To: On Thu, 19 Apr 2007, Johannes Schindelin wrote: > 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. Not only that, but there is then a _record_ that Joe Developer had to merge your work into his (or vice versa) ... -- Julian --- "MacDonald has the gift on compressing the largest amount of words into the smallest amount of thoughts." -- Winston Churchill