Nicolas Mattia

Thanks for the report. I merged that in a bit of a rush, I'll try to sort this out ASAP!

That's annoying. According to @edolstra, it's a server error: https://github.com/NixOS/nix/issues/1568 Looks like setting `accept-encoding` will correctly return a `gzip`, with `Content-Encoding: gzip` header: ``` shell $ curl -v -H 'Accept-Encoding:...

each source in its own file I believe is overkill, but i'm open to the idea of supporting several `sources.json`s. Definitely worth consideration!

Ah, looks like there's no `master` branch. Arguably `niv` could exit with a nicer error. You get a beer :)

Hey! I think that's a great idea, though `niv` might not be the best place, since it doesn't deal with `nixpkgs` at all. What about creating a new executable? [This](https://kamadorueda.github.io/nixpkgs-db)...

That sounds like a good idea. Maybe we can even unify this with the "template" feature used in e.g. URL templates (where `` in a string is replaced with the...

I think I agree with @nomeata here. The one big problem, which is the same problem blocking #111, is that there is not way to get the list of commits...

That means that `niv update --help` could infer from the applicative _which_ keys are read during the update (like `sha256`, `url`, etc) and could automatically provide command line flags for...

What about a flag like `--dry`? That means that `niv update nixpkgs --dry` would either show a diff, or the new version. I like the diff, I think some output...

Aren't channels being phased out in favor of flakes? I've never really used channels, how does that work? I.e., how would the CLI UX look like?