tere: 1.5.1-unstable-2024-04-01 -> v1.6.0

[timon-schelling]

Description of changes

https://github.com/mgunyho/tere/releases/tag/v1.6.0

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/)
• 24.11 Release Notes (or backporting 23.11 and 24.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.

[timon-schelling]

@ProducerMatt Changed The cargoHash, some of my overlays messed with it.

PS: sorry for PR 342144, I'm still not sure how I messed up that bad 😬

[ProducerMatt]

I think everyone does something like that once. I once ran a rebase and it somehow tagged in the past dozen unrelated commit authors. 🙃

You can avoid those dependency issues with nixpkgs-review.

Result of nixpkgs-review pr 342160 run on x86_64-linux 1

1 package built:

• tere

So LGTM

[timon-schelling]

In this case I somehow managed to squash a lot of nixpkgs into one commit. I guess lesson learned, I will never again rewrite history on a non draft PR on GitHub. Thanks for the kind words and the quick review :)

[ProducerMatt]

I somehow managed to squash a lot of nixpkgs into one commit.

Sounds exactly like what I did! The worst thing is it's not obvious it happened until it's pushed.

Personally when I'm unsure, I make a new branch and git cherry-pick <old>. Now that I think about it, I bet git commit --amend would work and be easier, but I haven't tested it yet.

[timon-schelling]

Personally when I'm unsure, I make a new branch and git cherry-pick <old>. Now that I think about it, I bet git commit --amend would work and be easier, but I haven't tested it yet.

I used --amend, I don't know how that can lead to squashing so many commits.