<1e1d23499a69570914f03bc0a196953a.squir...@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. _______________________________________________ nix-dev mailing list nix-dev@cs.uu.nl https://mail.cs.uu.nl/mailman/listinfo/nix-dev