2012/6/22 Ludovic Courtès l...@gnu.org
Eelco Dolstra eelco.dols...@logicblox.com skribis:
On 21/06/12 17:07, Ludovic Courtès wrote:
A hybrid policy is of course also possible. I.e. uncontroversial
changes (such
as minor package upgrades in Nixpkgs) can go directly into the master,
2012/6/22 Shea Levy s...@shealevy.com
I tweeted my surprise about this fact and got this response:
https://mobile.twitter.com/#!/xpaulbettsx/status/216003572163297280 . So
that might make giving more people commit access a more palatable solution.
This link is better:
Hi,
Kirill Elagin kirela...@gmail.com skribis:
Hello, this is git. Why are you against merge commits?
Automatic merge commits (when pushing something to a branch that has
been fast-forwarded in the meantime) make the history gratuitously
non-linear, and thus much harder to follow (both for
l...@gnu.org (Ludovic Courtès) writes:
Automatic merge commits (when pushing something to a branch
that has been fast-forwarded in the meantime) make the history
gratuitously non-linear, and thus much harder to follow (both
for humans and for tools like ‘git bisect’).
I typically address
Hi all,
I've just merged a patch that lets the NixOS initrd use BusyBox:
https://github.com/NixOS/nixos/commit/9692495df063703ffeafe53d75e8c3ca107bc68e
This shouldn't cause any problems, but initrds being what they are, there is
always the possibility that they break somebody's boot. So let
there are to important points to keep in mind:
(1) we want to trust the main stable branch (whatever that is) as much
as possible
This implies that arbitrary commits should get reviewed. However simple
patches can be reviewed most efficiently by batch processing.
(2)
we want new users to
We definitely should investigate [better-initramfs][1].
I've never used it yet (since I'm happy with genkernel), but I was just
going to look at it when I'll have free time (by the end of June), so I'll
let you know, what I think.
[1]: https://github.com/slashbeast/better-initramfs
--
Кирилл
On Fri, 22 Jun 2012 03:08:21 +0400, Kirill Elagin kirela...@gmail.com wrote:
2012/6/22 Eelco Dolstra eelco.dols...@logicblox.com
One slight complication here is that since GitHub doesn't disable
non-fast-forward commits, every committer actually *can* cause data loss
in the
repository.
