Re: GIT vs Other: Need argument

[Steven Grimm <koreth@midwinter.com>]

Jakub Narebski wrote:
> In my opinion the update-then-commit workflow CVS and SVN forces on users
> is one of the more annoying features, forcing the user to resolve conflicts
> if he/she wants to be up-to-date.
>   

I'm not eager to jump to svn's defense -- there's a reason I'm using git 
and trying to get my coworkers to do the same -- but how does git allow 
you to stay up to date without resolving conflicts? Granted that git is 
smarter about resolving certain kinds of conflicts automatically, but 
fundamentally if the latest revision you've pulled down (from any kind 
of version control system) makes a change that conflicts with a local 
change (whether or not you've committed it locally first) you're going 
to have to resolve it by hand, yes?

Also, last I checked, git wouldn't let me push into a branch that had 
revisions I hadn't yet pulled down. Isn't that just another way of 
enforcing an update-then-commit workflow? If anything, svn wins in that 
area -- it allows me to commit without updating as long as my change 
doesn't touch any files that have changed upstream.

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.

> The update-then-commit assumes that you merge on update local modifications
> with current server version, assuming that ancestor is current local
> committed version. This makes off-line committing impossible, and makes
> rare updates (server version advanced by more than one commit) unnecessary
> hard.

That last point is completely counter to my experience. At my company 
(where the svn repository is still the official code base) the 
repository is constantly changing. I'll sometimes let hundreds or even 
thousands of revisions go by between updates of my svn client. When I'm 
at a good point to do integration testing and I'm using an svn client 
instead of a git-svn one, I type "svn up", do roughly the same manual 
conflict resolution I'd do after a "git pull" that brought down a 
similar number of new revisions -- often none at all if I'm the only one 
working on a particular corner of the code base -- and I'm good to go. 
What's unnecessarily hard about that? How would it be any better in git?

Local commit capability is absolutely a huge win in git, though, and is 
one of the main features I use to sell people on it internally. No 
argument there. I just don't like being *forced* to do a local commit 
when I have no reason to do so other than to satisfy the version control 
tool. I end up either cluttering my history with dummy revisions or 
having to type extra commands to get rid of them.

And in particular -- this being the original topic of the thread -- when 
an svn user sees me doing that, they do not immediately think of the 
fact that merging between immutable revisions may have some benefits. 
They see me typing four commands (commit, fetch, rebase, reset) to do 
the same thing they can do in one command with svn, and conclude that 
git is harder to use. That some of them choose to use it anyway is a 
testament to how great git is in other areas.

-Steve