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 _______________________________________________ nix-dev mailing list [email protected] https://mail.cs.uu.nl/mailman/listinfo/nix-dev
