<div class="gmail_quote"><div><br>Rob Allen wrote <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div style="word-wrap: break-word;">
<div><div>(Going off topic here)</div><div>I've never used it, but understand that git is much much faster for branching and merging which is nice. Personally, with my Tech Director's hat on, I'm concerned about four main things with git in terms of introducing to the company:</div>
<div> 1. The two-step process required to get a commit to the master server (git commit, git push). I'm especially worried that devs will commit and not push and have no idea how easy it is for them to see what they haven't pushed yet. (Of course, it may be easy to automate this for all I know!)</div>
<div> 2. Windows support is not a first class citizen</div><div> 3. Easy switching of a working copy to a different branch means more developer care needed to ensure on correct branch before coding</div><div> 4. Lack of GUI tools and integration</div>
<div></div></div></div></blockquote><br></div><br>Rob, just thought I'd answer these:<br><br>1. You can a git status, and it will tell you that you are ahead of the server by X commits. This snippet from Git bash after I just committed something on a branch that is also on a server.<br>
<br>Dave@XP64 /d/work/npp/notepad-plus (IncludeRedux)<br>$ git status<br># On branch IncludeRedux<br># Your branch is ahead of 'joce/IncludeRedux' by 1 commit.<br>#<br><snipped rest of output><br><br>There are probably more sophisticated things you can do in order to tell exactly what hasn't been pushed. But, what I've found is, that even junior devs quite like the fact that they can commit on their own, then when they're ready to share it, they can push it.<br>
<br><br>2. Actually now Windows support is really quite good. msysGit is very stable, and comes with Git Bash, which is bash but optimised for git usage, so it displays the current branch you're on, tab completion for paths, branch and remote names, plus other good stuff which i'm either not aware i'm using, or don't know is there!<br>
<br>3. Actually, I think it's far easier to commit something to the wrong branch with svn than it is with git. See answer to point 4 (or point 2 if you prefer the command line). Plus, it is far easier in git to move a commit to a different branch, than in SVN. SVN would require (I think), reverse merge the rev on the branch committed wrongly, switch to correct branch, merge the rev from the wrong branch. Then you can run into problems if those two branches ever merge. Maybe there's an easier way..., but that's what i've had to do in the past.<br>
<br>4. That's not really true any more. TortoiseGit is actually really good now (that's quite a recent change, IMHO, when i tried it a few months ago, it was still a little buggy, but now it's spot on, and i use it regularly). And, unlike TortoiseSVN, because the branches have regular names, the context menu shows "Git commit -> yourBranchName", so it's obvious which branch you're committing on. I'm told Git extensions is very good too. <br>
<br><br>For me, from a work scenario, the barrier is getting the suits to understand the benefits of the distributed bit, rather than seeing the "we're losing control, we don't know where anything is, we've got no central server" attitude. The possibilities when you've got a few devs working on a project, and they need to share some code, and not share other bits, are really tremendous. <br>
<br>Plus, if you want, you can mirror the git repo to an svn repo. <br><br><dave steps off his soapbox now> ;)<br><br>Cheers,<br>Dave.<br>