git-fixup
git-fixup copied to clipboard
quodlibetor
Document Nixpkgs "installation method"
please ping this pr again then that one is merged, I probably won't be tracking it closely.
Hey, I got this comment there I don't particularly agree with, but I'm also not one to argue over such things. Would you have an idea how you'd have this named under the Nixkpgs namespace? quodlibetor-git-fixup, perhaps? Note that the executable name is not in question—that will remain git-fixup.
ehh I've considered renaming this to git-instafix because there are a bunch of git-fixup projects out there, you can even see that in the name of some env vars.
I can create a new project after the break that has that name, or you can feel free to propose it as an alternative name.
The big difference between this and the git-fixup that that maintainer linked to is that this project provides a richer ui for selecting the fixup commit, and automatically rebases for you.
Used a synonym list and a Google search to come up with these:
| name | status |
|---|---|
| git-fixdown | taken |
| git-alter | free |
| git-rectify | free |
| git-revise | taken |
| git-revamp | free |
| git-rework | free |
| git-re | free |
My favorite is git-re
thanks for the synonym list! I had a flu over the holidays and am still recovering, I'd hoped to get things cleaned up this last weekend but obviously didn't.
I'll see how this week goes, I'm excited that you're interested and will try and get it out but I've got a lot of life right now.
I wish you a graceful recovery, Brandon. I changed my mind. My favorite is your git-instafix. It's amusing and catchy.
I've updated the project to git-instafix and pointed out similar projects.
Thanks for your patience!
Note: the nixpkgs package would be more elegant if the path git binary were configurable, maybe consider adding this option in the future if you have time. (But you state that you intend to remove all dependencies on the git binary anyway, so this issue might just resolve itself.)
But you state that you intend to remove all dependencies on the git binary anyway
yeah currently the only dependency is for rebase, which gitoxide does not support and git2 didn't support. It's worth revisiting now that someone managed to get it merged into git2.
the nixpkgs package would be more elegant if the path git binary were configurable
Do you mean with a config file? Right now it should just pull it from PATH.
Do you mean with a config file? Right now it should just pull it from PATH.
With a compile time config. (I am sure there is some way to do this with cargo...) On NixOS programs can't rely on anything being in PATH, all dependencies have to be declared explicitly. If you look at https://github.com/NixOS/nixpkgs/pull/275402, right now an extra wrapper has to be defined just to provide a PATH value with the git binary.
With a compile time config.
Yeah that's easy enough to do, and there's a few ways. Do you have an example of something in any language being built in a way that follows nix best practices?
I looked around a bit, it seems that compile time env variables are the most common way to do this. Examples here and here.
You can use the option_env! macro to get an env variable at compile time. Then the logic would be to let's say use std::option_env!("GIT_BINARY_PATH"), if it returns a Some then use it, otherwise default to "git" as you currently do.
Version 0.2.1 (just released) switched the last piece from an external git command to libgit2, it no longer has any dependency on the git binary.
Sorry about the delay on this, I don't understand nix enough to know how I want to document it. I was trying to teach it but I'll just ask you.
My big concerns/questions:
- How does the nix package get updated? Is it automatic, and if so are there docs?
- does this being in nix mean it works with devbox, flakes, or other similar wrappers?
- what would be the easiest way for me to test the nix package?
Sorry about the delay on this, I don't understand nix enough to know how I want to document it. I was trying to teach it but I'll just ask you.
Sure. Look, Nix is a lot to learn. And there are different ways of using it. Therefore, there are no good answers:
- How does the nix package get updated? Is it automatic, and if so are there docs?
Depends on how it is used.
- does this being in nix mean it works with devbox, flakes, or other similar wrappers?
I'm not familiar with devbox. nixpkgs offers a flake. That flake includes git-instafix.
- what would be the easiest way for me to test the nix package?
Have nix with flakes enabled (install it via the DetSys installer) and run:
nix run nixpkgs#git-instafix -- --version
Learn more about nix at https://nix.dev . Feel free to message me for help, as well.
Oh when I said this:
How does the nix package get updated? Is it automatic, and if so are there docs?
I meant how does nixpkgs itself get the git-instafix update.
Looking at this PR it looks like it's automated someway? https://github.com/NixOS/nixpkgs/pull/322675 ? Is there anything I need do to make sure that it continues to work correctly? I mostly want to make sure that if something has a documented install method I know how to check if it's up to day and what went wrong if it's not up to date.
I meant how does nixpkgs itself get the git-instafix update.
Looking at this PR it looks like it's automated someway? NixOS/nixpkgs#322675 ? Is there anything I need do to make sure that it continues to work correctly? I mostly want to make sure that if something has a documented install method I know how to check if it's up to day and what went wrong if it's not up to date.
You're right. That is automated. But I don't know how it works. Probably looks at git tags in your repo.