Re: A failing attempt to use Git in a centralized environment

[Stepan Kasal <kasal@ucw.cz>]

Hello Marat,

On Mon, Apr 28, 2014 at 10:29:07AM +0400, Marat Radchenko wrote:
> Setup:
> 20 people (programmers, artists, designers) with prior SVN

I was in a similar situation: 10 people, mostly mathematicians,
previous experience with Tortoise SVN.

I wanted to move to Git with centralized model.  I call it a success:
people can do basic changes on master and also can work with
branches, if they don't want to break master.  (Much better than
keeping uncommitted changes at a svn checkout.)

I avoided TortoiseGit because I thought it would make the switch more
complicated: Git does differ from SVN, and it cannot be hidden.

We use Git Extensions (Windows only frontend).
I like it, as it is very close to command-line, so it is easy for me
to provide support.  It also improves the dialogs by hiding all the
advanced options; you have to click on "advanced" to get the full
list.

When working on master, pull --rebase is a necessity:
The install procedure does set config
  branch.autosetuprebase = always
(Must be done before any clone, so that all branches created after
that are set up to rebase, rtfm...)

I also told people to check "Rebase" in the pull dialog (it is
persistent then).

And I provided snapshots, so they immediatly call for help if they
see non-linear history.

> Problem #4: when conflict happens during rebase, mergetool shows
> user own changes as "theirs" and remote changes as "mine". And
> believe me, explaining this to users doesn't increase their
> willingness to adopt Git.

Our mergetool is Kdiff3.  (Git Extensions are willing to install it;
we did that separately to get a newer 64bit version.)
Kdiff3 shows three columns; their names (BASE, LOCAL, etc.) are
confusiong, but in our case it was easy to ignore them; we had no
previous experience with merge conflicts resolving.

> Problem #6: push - reject - pull - push sequence sometimes
> transforms into a loop with several iterations and doesn't add
> happiness.

I told people to do "pull-push" always when they want to push.
If the pull has conflicts, then they naturally do "pull-push" again
after the conflicts are resolved.

Git Extensions has its problems, you may look at the issue tracker;
I created several reports when exploring it (login kasal).

I would mention:
https://github.com/gitextensions/gitextensions/issues/2241

If you pull on a non-tracking branch, it creates a false
origin/branchname from origin/HEAD.  The bug was fixed, but there was
no release since then: so you have to live with it or you have to
build Git Extensions yourself in Visual Studio.

I had to write this in haste; hope this helps you anyway.

Stepan