Setup:
20 people (programmers, artists, designers) with prior SVN knowledge and a desire to use Git for a new project (mostly on programmers side). Non-programmers used TortoiseSVN before so choosing TortoiseGit as a GUI was an obvios step.
We made an in-house presentation introducing basic Git concepts and how it is different from SVN. Also, individual training was done for each person who didn't have Git experience. During this training, they tried everyday tasks of updating, committing, pushing changes and viewing history on a toy repository.
Problem #1: TortoiseGit GUI windows for common tasks have a heck lots of controls that a common Git user will never need. Just look at a monstrosity of its push dialog [1]. This was kinda fixed by training users to use Git Sync dialog [2].
"Autoload PuTTY key"? What the hell is this? Why I can switch it on/off in Git Push but it is disabled in Git Sync? What is PuTTY doing here at all, I'm using OpenSSH.
Problem #2 occured the first day we started using Git on real project. It is explained in detail in older post to Git ML [3]. I call it "swapped/reverse merge problem".
In short:
1. Hack, hack, hack
2. Commit
3. Push, woops, reject (non-ff)
4. Pull
5. Push
The root of evil is step #4 that creates a merge commit with "swapped" parents - local commits become first parent, remote commits become second. If one would want to make proper parent order, he would have to:
1. git fetch
2. git checkout origin/master -b tmp
3. git merge master
4. git push
5. git checkout master
6. git merge origin/master
7. git branch -d tmp
And all this branch dance produces exactly the same commit (content-wise) as simple "pull, push" sequence with the only difference in parent order. And things become even worse if comeone pushes more commits to remote repo while you perform this dance.
We can't expect all developers (especially, designers and artist) to do it. They don't want to use branches and just work on mainline. This is especially important on early development stages when new features (that designers' work depends upon) are added every day.
Additionally, many git-related tools depend on first-parent convention and show wrong graphs/diffs.
Problem #3: on conflicts, user ends up with a working copy that marks all remote-changed files as modified. Luckily, nobody has problems with conflict resolution process, it's just confusing to see changes other way round.
Okay, then, let's try rebase workflow. "git config pull.rebase true" and go.
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.
Problem #5 (TortoiseGit-related): for some dumb reason, TortoiseGit's rebase is not a git rebase! Worse, TortoiseGit doesn't have any button to say 'git rebase --continue". So we had to cancel "pull.rebase=true" approach and teach users to use "Fetch&Rebase" button. It would be usable if only TortoiseGit didn't show rebase dialog even when everything was already up-to-date. And even git-aware developers don't understand the idea behind "Force rebase" checkbox in rebase dialog and why anyone would ever want to have it disabled (and it is disabled by default).
Problem #6: push - reject - pull - push sequence sometimes transforms into a loop with several iterations and doesn't add happiness.
So... Any suggestions how to make life easier are welcome.
[1] http://tortoisegit.googlecode.com/git/doc/images/en/GitPush.png
[2] http://tortoisegit.googlecode.com/git/doc/images/en/GitSync.png
[3] http://git.661346.n2.nabble.com/first-parent-commit-graph-layout-and-pull-merge-direction-td7586671.html
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
From: Max Kirillov <hidden> Date: 2016-06-15 23:00:59
Hi.
Problem #6: push - reject - pull - push sequence sometimes transforms
into a loop with several iterations and doesn't add happiness.
As far as I undestand, this is the most annoying thing. In
git (like other distributed systems), you cannot push your
changes unless you merge them with a very last version of
the whole repository.
I think the only good way to use git in a team with more
than a very few persons is to switch to pull-request based
workflow, which does not require users to update to push
their changes. Then their changes are merged to master
either by a human integrator or by a tool (gitorious,
github, stash, gerrit etc.).
I think it can be even as little as 'update' hook, thich is
triggered when user pushes to branch like 'inbox/bob' and
tries to merge the branch to master. The only issue I can
see with it is that does not provide a way to specify
meaningful merge message.
Btw, then the problem#2 is not a problem, because the merge
done by user does not yet produce the commit to be added to
master, but just prepares more recent version - to resolves
conflicts or check how the changes work against newer
codebase. One more merge is still performed by the server,
and parent order is correct:
master =====+===+======2
\ \ /
your copy +===1==+
--
Max
Just do pull --rebase? This is essentially the same as what SVN
used to do in your setup.
That's not necessarily a good solution either. For teams that don't
use rebase, it can leave them with their newly committed stuff now
rebased on the work from upstream--duplicating commits without
understanding why and where they came from, especially if other
branches were built on top of that one.
I agree in concept, but in practice it can be quite confusing. :-(
-John