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��.n��������+%����;��w��{.n��������n�r������&��z�ޗ�zf���h���~����������_��+v���)ߣ�
