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
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 . This was kinda fixed by training users to use Git Sync
"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
Problem #2 occured the first day we started using Git on real project. It is
explained in detail in older post to Git ML . I call it "swapped/reverse
1. Hack, hack, hack
3. Push, woops, reject (non-ff)
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
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
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.