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
-
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