git-publish: init at 1.8.1

[lheckemann]

Description of changes

Init package.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 22.11 Release Notes (or backporting 22.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
  • (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes
• Fits CONTRIBUTING.md.

[lheckemann]

Undrafted, I think I'll be using this enough that I can maintain it :)

[SuperSandro2000]

Suggested change

	{ lib, stdenv, python, perl, fetchFromGitHub }:
	stdenv.mkDerivation rec {
	{ lib, stdenv, python, perl, fetchFromGitHub }:
	stdenv.mkDerivation rec {

[lheckemann]

Do we have a written convention for this now? If not I won't apply this.

[SuperSandro2000]

@teto How about you are not being passive aggressive?

[SuperSandro2000]

@lheckemann we do not have written rules for literally everything and I don't want to write rules for everything. It would make it a lot easier if you could just incorporate style changes together with the other 3 changes. If it would be the only comment then I would have completely ignored it. Thank you.

[lheckemann]

The thing is: I prefer the style that I wrote. As long as we don't have a rule saying what the preferred variant is to resolve matters of pure opinion like this, I don't think it makes sense to have these discussions.

I'm grateful for your reviews that bring my attention to useful things like installManPage -- I think we can all agree that using abstractions like this where they exist makes sense.

But things that are matters of pure opinion, like this blank line here, are a waste of time. I'd appreciate if you could limit yourself to the actually useful things -- or policies that are actually written somewhere, so i don't have to guess what "SuperSandro2000-conforming style" is -- in future reviews of my code.

[SuperSandro2000]

@lheckemann can you activate that maintainer can push to your branch? That makes things a lot easier and faster to merge.