[Nix-dev] Re: new possible movement to git (?)

Peter Simons simons at cryp.to
Tue Aug 30 15:03:10 CEST 2011


Hi Shea,

 >> The whole notion of having a "stdenv-updates" branch in the first
 >> place is obsolete in Git. Instead, we would have many small topic
 >> branches for specific features.
 >
 > But stdenv-updates isn't meant as a really big topic branch. It's
 > meant as a place for changes that will require rebuilding the system,
 > so we can minimize the number of times we require that. How does git
 > help with that?

Suppose that I modify GNU Make, for example, then that change ought to
go into stdenv-updates. At the same time, you modify glibc, and that
change goes into stdenv-updates, too. But those two changes are
orthogonal. They don't depend on each other. So why should they be
checked into the same branch? There is no conceptual reason to do that.
Rather, there is a practical reason, namely the fact that creating two
new branches for those two changes -- a.k.a. topic branches -- would be
unfeasible with SVN.

When using Git, that restriction no longer exists. I can create a branch
stdenv/gnu-make, and you can create a branch stdenv/glibc, and Hydra
could build both of them (in fact, Hydra would probably build all
stdenv/* branches). In that scenario, other users are free to merge the
contents of either branch into their personal "master"; they can choose
whether they want to have the latest gnu make or the latest glibc or
both. When both changes are checked into one monolithic stdenv-updates
branch, however, doing that is not so easy.

Eventually, you decide that the new glibc is stable, and then you run
"git merge stdenv-updates" on whatever happens to be your equivalent of
the official master branch, and then you push the changeset upstream,
which effectively makes them "stable" for everyone. The merge commit
would even record the fact that you worked on a topic branch prior to
that, and the history of that branch would become visible in "master",
too.

The workflow is not completely different from what we are doing now, but
the granularity is much higher. There isn't just one stdenv-updates
branch. Rather, there are many of them.

Basically, all branches except "master" are considered unstable, i.e.
work in progress. When they have become stable, though, then they are
pushed into the master branch.

Take care,
Peter




More information about the nix-dev mailing list