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

2011-08-30 Thread Michael Raskin 
1e1d23499a69570914f03bc0a196953a.squir...@webmail.shealevy.com
87ei034yse@write-only.cryp.to
5833f9f3-bf70-4cae-9ad2-489170ad5...@email.android.com
87ei03aw6p@write-only.cryp.to
894aedf1c3c6d28c2272e35ab266d932.squir...@webmail.shealevy.com)
Mime-Version: 1.0
Content-type: text/plain; charset=UTF-8

  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.

exactly who is we? Please speak for yourself. I, for one, do not want
unrelated changes to be merged in one commit, because that habit breaks
extremely useful tools such as git bisect.

One commit and one branch are different things. 

Besides, having many different stdenv/* topic branches does not imply
that each of them must be merged into master separately. You *can* merge
them all at once, of course, if you want to. It just so happens that I
wouldn't want to do that because the practice violates elementary
principles software engineering.

The problem is that actually merging them one-by-one is costly. Trunk
should receive one rebuild. And it is established practice to reduce
the count of stdenv rebuilds.

Also, there is little happening in NixPkgs that should be classified as
software engineering. Everything non-trivial in packaging is about 
finding out upstream quirks. 

To run NixOS, I need maximum amount of packages in stdenv-updates to be
non-broken. Tracking what is broken where across five topic branches is
insanity even without second-guessing what will start working on merge.



___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev

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

2011-08-29 Thread Michael Raskin 
1e1d23499a69570914f03bc0a196953a.squir...@webmail.shealevy.com
87ei034yse@write-only.cryp.to)
Mime-Version: 1.0
Content-type: text/plain; charset=UTF-8

 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.
if you want branch to show in history you would have to push that branch
ti remote repo as well (using --no-ff option).

but as Peter pointed, branches in git are matter of local higene. You
name it however you want and make sure you merge them to remote branch.
Git doesn't force to you specific branching policy localy while still
playing nice with policy used on remote branch.

Well, remote branches are just local branches for the remote repository.

So the naming questions apply to them. 




___
nix-dev mailing list
nix-dev@cs.uu.nl
https://mail.cs.uu.nl/mailman/listinfo/nix-dev