[oi-dev] Git as a version control system for new OI projects

[Colin Ellis]

Damn.  I still think in 'cvs' commands

On Thu, Jun 23, 2011 at 11:14 AM, Guido Berhoerster <gber at openindiana.org>wrote:

> Hello,
>
> * Andrzej Szeszo <aszeszo at gmail.com> [2011-06-23 02:06]:
> > Latest upstream ips/pkg5 tools need more and more changes to make
> > them work with OI and illumos. I have asked the version control
> > system question because I wanted to create a repository for pkg5
> > with the changes.
> >
> > I wanted to avoid mercurial + mq patch queue solution and started
> > experimenting with git as I've heard good things about its rebase
> > feature.
> >
> > With some help from hg-git I was able to prepare git repository with
> > untouched branch which is tracking upstream pkg-gate + branches with
> > local modifications. I was then able to pull in upstream changes and
> > rebase customized branches without too much effort.
> >
> > Nice rebase functionality, cheap non-permanent branches, ability to
> > use hg frontend with hg-git extension and also availability of very
> > good 'Successful Git branching model' document [1] makes Git worth
> > considering on the backend in my opinion.
> >
> > Also, I think model descibed at [1] is worth adopting in terms on
> > how to organize the repository/branches. It would save us time on
> > re-inveting repository layout and documenting it for starters. Also,
> > apparently it proved to be successful for many people. People at
> > Joyent use this model - they can't be wrong ;) [2]
> >
> > By the way - I quite like mercurial. If someone can demonstrate how
> > to do rebase but using mercurial I'd be willing to try it out.
> > Thanks in advance!
>
> if I understand it right you want
> a) lightweight feature branches which are easily removed after
>   merging them into the master branch
> b) maintain a permanent branch with OI-specific changes and
>   rebase it on top of Oracles upstream branch
>
> For a) mercurial offers completely anonymous branches, ie. when
> you just commit on top of any changeset (this is not really
> viable with git) or you use the bookmarks extension which allows
> you to actually label such a branch. Bookmarks can be completely
> removed after merging a such a branch and thus resemble the
> behavior of gits branches [1].
>
> For b) mercurial offers the rebase extension which provides
> equivalent functionality as gits rebase. The question is why we
> should actually do this for a long-lived named branch rather than
> explicit merges.
>
> Anyway, both workflows (whether they are adequate for our
> purposes or not) are easily possible with mercurial.
>
>
> [1] There are two caveats with bookmarks, first you always want
> to ser "track.current = True" so that only the currently active
> bookmark and not all bookmarks pointing to a changeset get moved
> forward when you commit on top of it (this brain-dmaged default
> is gone from mercurial 1.8) and you need mercurial 1.6 to
> push/pull bookmarks between repos.
> --
> Guido Berhoerster
>
> _______________________________________________
> oi-dev mailing list
> oi-dev at openindiana.org
> http://openindiana.org/mailman/listinfo/oi-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openindiana.org/pipermail/oi-dev/attachments/20110623/591b2ac1/attachment-0005.html>