vscode-extensions.illixion.vscode-vibrancy-continued: init at 1.1.44

[2hexed]

added illixion.vscode-vibrancy-continued theme extension for VSCode which enables transparency and blur

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.

[JohnRTitor]

Please add the extension in alphabetical order.

[2hexed]

Please add the extension in alphabetical order.

How do I sort it in alphabetical order again? Would I have to do it manually by going through each extension name?

[JohnRTitor]

Please add the extension in alphabetical order.

How do I sort it in alphabetical order again? Would I have to do it manually by going through each extension name?

Yes, that's the approach I know of.

[JohnRTitor]

After you move it to a proper spot, please squash your commits. (Look up on Google if you don't know how)

There should be two commits, one adding you to maintainers list, and then one adding this extension. Second commit, which adds this extension should be same as the PR title (I just renamed the PR)

[JohnRTitor]

Are you perhaps not using Git locally? ie, editing Nixpkgs through GitHub's online interface?

[2hexed]

Are you perhaps not using Git locally? ie, editing Nixpkgs through GitHub's online interface?

I'm working locally whilst using 'Sync Fork' from the Github Web

Does everything look alright? Are there any other changes that I'm required to do?

[JohnRTitor]

whilst using 'Sync Fork' from the Github Web

I think GitHub provides a sync with rebase option as well in PRs? Anyways, you don't need to use GitHub to do periodic merges with master.

git fetch upstream
git rebase upstream/master

Should rebase the current branch on top of upstream/master. This is equivalent to syncing with master with a rebase on GitHub. This effectively recreates the commits (your commits), with new hash/new timestamps as if they are wholly new commits. This one is preferred when doing merges in contributor (like yours) forks.

However, syncing by "merging" (what you have been doing), is equivalent to git merge upstream/master. This preserves the Git history, and does not recreate the commits (yours), but this creates a merge commit as well. To keep a clean commit history, we do not recommend merge commits in contributor forks.

To be honest you don't even need to do periodic merges or rebases, unless there is a merge conflict. (GitHub will show if the PR has a merge conflict). In case of merge conflicts, you need to resolve the merge conflict before rebasing/merging.

As for "squashing" your commits, you can do that, by going into interactive rebase mode git rebase -i HEAD~6, an editor in your terminal will pop up. HEAD~6 is how far you want to go back, since you have six non-merge commits in your history, you should do HEAD~6.

You will see something like this in the editor:

pick dsdfsf4 commit1This is the commit message
pick fsfstrdsf commit2This is the commit message

To squash (merges two commits together), you can change second commit's pick to squash.

pick dsdfsf4 commit1This is the commit message
squash fsfstrdsf commit2This is the commit message

Again another edit window will pop up asking if you want to edit the new commit message, which would be commit1 message + commit2 message. You can edit however you wish and save, this should complete the squashing.

The reason we recommend squashing "fixup" commits (as in you fixed an issue with the previous commit), is, again, to keep a clean commit history.

Note that, you will usually need to force push your branch to the remote (GitHub), if you have done any kind of rebase, as GitHub won't allow overriding commit history easily. You can do so by git push --force.

If this sounds confusing to you (I am sure it is, it was confusing for me too), you can test git commands in a test repo. There are a lot of tutorials on Youtube to follow for Git.

However, just this once let me fix the commits as the commit history is quite complicated (as in the commit adding you to maintainers list should be the first commit, then the successing commit should add the extension). I will merge after I do so.

[nixpkgs-ci]

Successfully created backport PR for release-24.11:

• [Backport release-24.11] vscode-extensions.illixion.vscode-vibrancy-continued: init at 1.1.44 #387496

[nixpkgs-ci]

Git push to origin failed for release-24.11 with exitcode 1