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

From: Stepan Kasal <kasal@ucw.cz>
Date: Apr 30, 2014, 16:12 UTC
Message-ID: <20140430161215.GA24017@camelia.ucw.cz>
In-Reply-To: <4ay6w9i74cygt6ii1b0db7wg.1398433713382@email.android.com>

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