Samba GIT Mini-HOWTO

Gerald (Jerry) Carter jerry at
Thu Oct 4 21:33:28 GMT 2007

Hash: SHA1

Gerald (Jerry) Carter wrote:

> The "unstable" tree is a shared repository open for all Samba
> Team developers with an ssh account on and is
> the first code base run on the buildfarm.  Developers should
> use this branch (e.g. v3-2-unstable or v4-0-unstable) when
> testing portability issues, regression testing, and other
> features supported by Samba's buildfarm infrastructure.
> The "test" and "stable" branches are maintained by the
> series release manager.  When a developer has a feature
> that is complete, has passed the build farm tests, and
> is ready for widespread testing, an email should be sent
> to the samba-technical mailing list asking for the RM to
> pull from the developers feature "test" branch.  Assuming
> that the changes passes code review and are approved by
> a majority of developers, the code is pulled into the series
> "test".  The RM may then merge is the changes from his/her
> "test" tree to "stable" once sufficient testing has been
> done to ensure that the change integrates cleanly into the
> tree with no known regressions.
> The "stable" tree performs the role of the previous svn
> branch SAMBA_x_x_RELEASE trees and is the code base from
> which release tarballs are cut and signed. The RM is
> responsible for tagging releases from this branch.

Some clarifications on relationship between "unstable" and "test".
As a RM, I don't care what goes into "unstable".  That's only
to deal with continuing support for the build farm and
portability testing.  Consider it a private development playground.

However, the further the code in "unstable" is from "test" the
less useful it is.  So ideally, "unstable" should become a
pre-staging ground for "test" where people can push to ensure
that things work together in the build farm.  As the 3.2 RM,
I will ignore "unstable".  As a developer, I will use it.

But when it comes to get changes/features into "test" tree
which is the on-ramp to "stable", you must put your changes
into a local feature branch created from upstream "test"
and I will pull from that.

Changes should be grouped in related changes.  You should
have multiple "test" branches depending on how many features
you are working on.  But only one unstable branch since
you can just glob all you changes in that for the build farm.

For example, assume I'm working on two features foo and bar.
First I clone the samba-draft repo (if not already):

  $ git clone git:// samba
  $ cd samba

Next, assuming I have ssh access to the blender(unstable)
tree, I add a remote ref to it  and fetch the unstable branches:

  $ git remote add blender \
  $ git fetch blender

The previous two steps only need to be done when setting up your
local repository.

Next, I create two feature branches:

  $ git checkout -b foo v3-2-test
  $ git checkout -b bar v3-2-test

Now I do my work on each feature in its own branch.  When I want
to push to the build farm, I do the following: [1]

  $ git checkout -b v3-2-unstable blender/v3-2-unstable
  $ git merge foo
  $ git merge bar

  ## Necessary the upstream unstable tree has changed
  ## since you last fetched
  $ get-fetch blender
  $ git-merge blender/v3-2-unstable

  $ git push ssh:// \

Now when "foo" is done, You simply ask me to pull "foo" from your
repo.  The "bar" branch is untouched until your are through.

Hope this helps to clarify things a bit.

cheers, jerry

[1] Since the "unstable" tree is so different from "test", it
    might be better to throw the current "unstable" away and
    branch it against from "test".  Otherwise, the git-merge
    may turn into a git-cherry-pick.

Version: GnuPG v1.4.2.2 (Darwin)
Comment: Using GnuPG with Mozilla -


More information about the samba-technical mailing list