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

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