Re: GIT vs Other: Need argument

Johannes Schindelin [off-list ref] writes:

How is that not concurrent? If it really was not, there would be no need 
to merge.

It can be concurrent, but on different files. Concurrency and merge at
the filetree level, but never within a file. I've worked in a team
where the "corporate" use of a VCS was following this model. Not
locking a file before editing it was considered a mistake.

quoted

So for such people, I really think raw Git is much more complicated than 
CVS/SVN.

I imagine that somebody dedicated enough -- i.e. not me -- could set up 
some standard aliases which do the CVS/SVN equivalent; we'd probably need 
to support something like

	[alias]
		ci = commit -a && push origin

which should not be all that hard.

It depends on how you implement that.

There have been a discussion crossposted here and on the bzr ML. The
author of cogito added a similar feature to cogito.

But to emulate the centralized model, you need more than that, you
have to

1) make sure you're up to date with upstream
2) commit
3) push

and to do it correctly, 1) must be checked during all the procedure,
and doing it in a transactional way is not trivial.

bzr has a notion of "bound branches". That is, when you commit to a
bound branch, you also commit to the master branch. And the UI for
that is to use "bzr checkout master-branch". I agree the centralized
model is inferior in general, but there are several cases where this
is handy. One of them being to teach a newbie: "see, learn checkout,
update, commit, add, mv, remove and you know how to use it". Another,
for me, is to avoid forgetting to push ;-).

-- 
Matthieu