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

[Michael Raskin]

<1e1d23499a69570914f03bc0a196953a.squirrel at webmail.shealevy.com>)
Mime-Version: 1.0
Content-type: text/plain; charset="UTF-8"

>Hi,
>
> >> Given that branches are mere pointers, I don't see how to find out
> >> what was stdenv-updates before after it has been merged into trunk
> >> and re-created
> >
> > Yeah, it would be nice if git had information in commits about which
> > branch the commit was initially performed on. This seems like a
> > really simple feature, not sure why it doesn't exist.
>
>personally, I don't see why that information is relevant. Branch names
>are a local affair in Git. It's quite possible for two repositories to

So large projects model persistent branches with separate repositories,
and still cannot keep track of what went where in the first place.

>track the same content using completely different branch names. So why
>bother recording the name if it doesn't have any significance outside of

This is sometimes reverse thinking. What you say is "Git doesn't provide
nice tools to work with global branches, so they are useless". 

In Linux, separate "feature" branches are global and persistent. They 
use separate repositories to distribute load and because Git doesn't 
give them anything else. In Mozilla separate branches follow a naming
system and live inside one repository. We do want long-lived global
feature branches - if not, why not simply have SVN as the main repo
and use whatever system you prefer for tracking local changes? Because
SVN does allow global bracnhes?

Mercurial used to have way of dealing with branches similar to what you
described; they allowed keeping more data about intentions to fix the
interface. Git makes complete format stability one of its ways to ensure
overall reliability of the system, so it is unlikely Git will allow to
store any new kinds of information about commits in-repo.

>the repository? Other DVCS make a lot of fuss about branch names, like
>monotone, but I don't see any gain in a distributed project. 

Monotone promotes a consistent culture of naming branches. The basic
things that come from that is that I can sensibly manage one Monotone
database and make checkouts of whatever project I need when I need them.

>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.

Well, we could call our stdenv-updates branches "add-glibc-2.7" etc.
We didn't do it as a matter of development organization, not because of
some VCS matter. 

It is impossible to make stdenv-updates branch small if you want 
anything to work after the merge - even GNU TLS updates often break some
networking applications; gcc updates require rechecking most other 
packages. Sometimes it is prefereable to update many packages and then
wait for upstream fixes in some more. So this branch will not be 
short-lived - most probably, neither in days nor in commits.

Stdenv-updates has a few meanings conveying developer intent: first, it
is a branch where full-rebuild updates go; second, Hydra has a task to
build stdenv-updates branch; its static name means that the task is 
simply switched on and off, not changed every time. That way there is 
less place for mistakes - and so less burden for Hydra maintenance. 

>Also, I'm not quite sure why there should be an extra "stable" branch.
>As far as I am concerned, "master" ought to be stable.

You either shift the problem or understand it not in a way others do.

There is some code line that is build by Hydra and that is hoped to be
somewhat stable. Currently it is trunk. So people simply translate it
as "master". It is unlikely that every revision of it allows to build
every package in some checklist including Firefox and OpenOffice. Simply
because mistakes do happen and there is no way to ensure that a 
well-tested update of some package doesn't cause some part of dependent
packages to fail. 

Next, there is a stream of commits which were actually built by Hydra. 
Git doesn't allow tracking it all inside VCS, but the latest can be the
head of some auto-shifted branch or bear some tag.

Next, there could be some way to get the latest commits that, say, make
a few NixOS feature-tests pass.

The "stable branch" discussed in this thread consists of hand-picked 
commits that pass all formal tests and do not cause noticeable problems
in actual use. 

Once can want "master" to be that "stable" branch or one may want to 
have a separate "stable" branch - but the question of hand-picking 
stays. There is also a question of what formal criteria to set if we
want Hydra-related branches, too.