gitSetupHook: init

[drupol]

This PR:

• add a new hook gitSetupHook which initialize the git user.mail and user.name
• update a couple of derivation by using that new hook

Note: the hook uses a hook substitution for gitMinimal so that the user is still able to customize the version of git in use in nativeCheckInputs.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• 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/)
• 25.05 Release Notes (or backporting 24.11 and 25.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
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[winterqt]

Please reduce the diffs of the packages to just the setup hook usage, there is no point in doing that here—especially not in the same commits!

[nyabinary]

Please reduce the diffs of the packages to just the setup hook usage, there is no point in doing that here—especially not in the same commits!

It really doesn't hurt anyone, it's mundane changes, if it can be done in this PR I don't see why not :P

[winterqt]

It really doesn't hurt anyone, it's mundane changes, if it can be done in this PR I don't see why not :P

Hard disagree. They’re changes that don’t make any sense to do here, and especially not in the same commits that touch other areas of the packages.

[winterqt]

@nyabinary Please see the contribution guidelines for more information on this subject.

[ethancedwards8]

This feels like bikeshedding. Sure, they're not directly relevant, but reverting the changes would be wasting time and it would take even more time and reviewer/maintainer bandwidth to make the changes in another PR. Practically speaking, they're fine to stay in IMO. We are trying to maintain a complex and heavily used package ecosystem here, not be the perfect software development model. Just my two cents. Feel free to ignore.

[lilyball]

You know what wastes time? Putting a bunch of unrelated changes into a PR, and then arguing about it. It's not even your PR and you're arguing!

[drupol]

Let's all calm down, splitting my work in two PRs is a matter of half a minute, it's actually super easy to do with jujutsu.

I am going to do it as soon as I am out of bed.

[drupol]

This feels like bikeshedding. Sure, they're not directly relevant, but reverting the changes would be wasting time and it would take even more time and reviewer/maintainer bandwidth to make the changes in another PR. Practically speaking, they're fine to stay in IMO. We are trying to maintain a complex and heavily used package ecosystem here, not be the perfect software development model. Just my two cents. Feel free to ignore.

You're right that, technically, we should avoid mixing concerns in a single commit or PR.

In this case, my PR does mix a few distinct changes:

1. Switching to gitSetupHook
2. Switching to finalAttrs
3. Minor clean-up (e.g. removing "with lib;")

If I were reviewing this PR myself, I wouldn't have requested changes either, mainly because I know how limited our time and resources are, and I appreciate it when someone takes care of these improvements, even when bundled (In fact, I often take the same approach when reviewing, but I rarely ask for such commits to be split.).

However, the context here is slightly different. Self-merging isn't an option, and I'm still learning the ins and outs of hook usage. That’s why I’d rather have it reviewed thoroughly, even if it means splitting it.

No worries at all about the request, I'm not offended or frustrated. I know some contributors might have closed the PR in response to such feedback, but that’s not how I approach collaboration.

[drupol]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 402320

---

x86_64-linux

⏩ 2 packages blacklisted:

• nixos-install-tools
• tests.nixos-functions.nixos-test

✅ 1 package built:

• gitSetupHook

[drupol]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 402320

---

x86_64-darwin

✅ 1 package built:

• gitSetupHook

[ethancedwards8]

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 402320

---

aarch64-darwin

✅ 1 package built:

• gitSetupHook

[drupol]

@winterqt Planning to merge this by the end of the day, if you have some more feedback, please share them here so I can work on this.

[winterqt]

I'm not sure if we should add this to the changelog at this point -- we're already very close to release. cc @leona-ya

[leona-ya]

This depends on what the first release that this changes reaches it. If it gets merged before release to 25.05, I'd say 25.05 changelog, otherwise 25.11

[drupol]

Fair enough, planning to merge this today by the end of the day, so 2505 is still fine.