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

[shea at shealevy.com]

Hi Peter,

I don't think this accurately reflects the reasons we use stdenv-updates.
We don't put it all in the same branch because more fine-grained branching
is expensive, we put it all in the same branch because we want the
eventual merge of the changes to happen at the same time. We will still
have that requirement for the public nixpkgs repo if we switch to git.

~Shea

> 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
> nix-dev at cs.uu.nl
> https://mail.cs.uu.nl/mailman/listinfo/nix-dev
>