Public Git repo

[John Ralls]

On Jan 10, 2011, at 8:13 AM, Colin Law wrote:

> On 10 January 2011 15:56, Jeff Kletsky <gnucash at allycomm.com> wrote:
>> At least as I understand it, branches in git are nothing more than a pointer
>> to the "head" commit and, structurally, are pretty much the same (if not
>> identical) to tags. A branch in git is a tag on point in development that is
>> moved to other commits if you commit "to" that branch. In simpler words, it
>> is a tag that gets conveniently moved each time you commit. You really
>> aren't "working on/in a branch" but are more moving what the notion of the
>> head of the branch is. Yeah, it's really different from svn that way.
> 
> It may well be true that branches and tags in git are structurally
> very similar, but in terms of operation they are completely different.
> Git knows the difference and handles the concept of "working on" a
> branch in virtually the same way as svn (as far as the user is
> concerned).  So one can create a new branch, make changes, committing
> along the way.  One can use gitk to give a graphical representation
> showing the branch separate from other branches.
> 
>> 
>> While there is the notion of "parent" and "child" commits (which can be
>> multiple) in git, one of the things that is different about git branches is
>> that there is no notion of a "branch point" or a "branch history" the way
>> there is in svn, for example.
> 
> Up to the point of merging there is effectively a branch point and history.
> 
>> Sure, as long as you don't merge the branch,
>> you can determine where it diverges from another branch. However, once you
>> merge, that gets dicey to impossible.
> 
> That is true, once a branch is merged into the master branch, for
> example, it is as if the changes were made on the master.  Personally
> I have not found this to be an issue.
> 
>> As long as you don't really care where
>> you came from and how, git branches are fine. They can take care of
>> * most recent 2.2-Release version
>> * most recent 2.4-Release version
>> * most recent Stable version
>> * most recent Current (bleeding-edge) version

This is absolutely not true, and spending a few seconds with a history visualization in git-gui or the "network" view on Github will show it. (With git gui, you have to pay attention to the colors of the links between commits: They indicate in which branch the commit was made.) It's SVN that loses identity unless the merge commit mentions it in the comment: A merge is represented as a single patch on the merge-to branch (trunk is a special branch). Github's visualization is especially cool because it tracks pulls across multiple repositories on Github. 

As Jeff mentioned in passing, any commit can have multiple children (a branch point) and multiple parents (a merge point). (Only parents are recorded in the commit object; children have to be reconstructed.) The git history plumbing follows those branches and merges and displays them correctly -- as long as one uses the tools correctly.  It's possible with git to replay the changes in one branch onto another branch (git cherrypick), which creates a new set of commits on the receiving branch which have no references to the original. 

See http://utsl.gen.nz/talks/git-svn/intro.html for a good exposition on migrating to git from svn and how to get more from git, as well as a comparison of svn, svk, git, darcs, bzr, and Hg.

Regards,
John Ralls