[Openmcl-devel] How about Git?

[mikel evins]

> On Nov 29, 2015, at 4:15 PM, Tim Bradshaw <tfb at tfeb.org> wrote:
> 
> On 29 Nov 2015, at 21:57, mikel evins <mevins at me.com> wrote:
> 
>> - working with git requires an initial adjustment; the equivalent of checking out or checking in requires an extra step as compared to Subversion—for example, for “check in” you first “commit” (check your changes into the local repo), then you “push” (transmit the updates to any remote mirrors). This isn’t that complicated, but I’ve noticed several people having trouble with it at first.
> 
> FWIW the way to explain this to SVN people is that clones are branches: you (add and) commit to the local repo (branch) then push to the remote (merge your changes into the trunk).
> 
> (I know, the analogy isn't exact, since there are branches in git as well, but clones are more like SVN branches than git branches are in many ways.)

The way I’ve had good success is by drawing a picture. I had the experience a couple of times of explaining it several times in words and getting puzzled looks, then drawing a simple picture. Working copy connects to local repo connects to remote repo. Commit points from working copy to local repo. Push points from local repo to remote repo. Pull points from remote repo to local repo. Update points from local repo to working copy.

That always seemed to do the trick.

One other possible benefit is that git (and Mercurial) branches and merges are really really quick and easy. I don’t know what branching and merging are like in Subversion nowadays, but they used to be much less convenient than in git and mercurial. As a point of reference, a common workflow with git and Mercurial is to create a branch for any new work you do. When branching and merging are quick and easy enough, it works as a nice way to isolate one person’s changes from another’s, while enabling different people to easily cherry-pick each other’s work.