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 

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.


Reply via email to