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

[Guido Berhoerster]

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