siedentop / git-quickfix Goto Github PK

I have decided to remove the git-qf alias in a future release.

Please vote with (👍👎) on this ticket to express your opinion. A threshold of ~25% voting "Keep" would mean, I keep it.

👍: Remove qf alias.
👎: Keep qf alias.

Also, feel free to leave comments below.

Why I want to remove it:

1. It is literally the same binary twice. Not a shell alias, nor a symlink.
2. Cargo warns about this. I don't like warnings.

for example this is how I update default branch without switching to it:

git fetch -f . "$REMOTE_AND_BRANCH":"$BRANCH"

or with the script git fm

Source https://github.com/rofrol/dotfiles/blob/master/bin/git-fm

$ git qf readme-updates --onto develop
$ git log --oneline -3 readme-updates
f0ff363dde36 (readme-update) README: clarify unofficial nature
859ab94104e5 README: clarify unofficial nature
b6390003b6bb (HEAD -> develop, origin/staging, origin/develop, origin/HEAD) Merge #114

Here, f0ff363dde36 is an empty commit generated by git-quickfix, and 859ab94104e5 is the actual commit that I had on my develop branch and wanted to be moved. I tried locating where exactly this fails in the code but didn't make much progress, probably due to my lack of git2 knowledge.

Thank you for creating this. This is a really useful git addon!

Unless --keep is provided, the quickfix commit will be removed.

This came as a surprise to me (because I didn't finish reading the documentation before trying the tool 🙄). I would argue that --keep should be the default. Even if the "quickfix" commit does not naturally belong into my feature branch (topic wise), I usually like to keep them around. Because it's often not just a typo or documentation change, but an actual bugfix that I need in order to develop my feature. And I don't see any downsides (except maybe "cosmetic" ones), because my branch will later cleanly merge into master if that bugfix has already made it to master.

I realize this would be a breaking change, but maybe it's worth discussing. Otherwise, I'm also fine with (usually) providing --keep of course.

~PROJECT_ROOT/src tmp/feature1
❯ git status
On branch tmp/feature1
nothing to commit, working tree clean

~PROJECT_ROOT/src tmp/feature1
❯ ~/devel/git-quickfix/target/release/git-quickfix tmp/minor1
Error:
   0: The repository is dirty.

Suggestion: Consider auto-stashing your changes with --stash

Backtrace omitted.
Run with RUST_BACKTRACE=1 environment variable to display it.
Run with RUST_BACKTRACE=full to include source snippets.

Version: b8e7051 (branch bugfix/support-dirty-workspaces (PR #3 ).

The --stash functionality of git-quickfix is similar to gits own --autostash option for a few commands. It doesn't simply stash (push) the local changes, it also stash pops afterwards.

From man git-rebase:

       --autostash, --no-autostash
           Automatically create a temporary stash entry before the
           operation begins, and apply it after the operation ends. This
           means that you can run rebase on a dirty worktree. However, use
           with care: the final stash application after a successful
           rebase might result in non-trivial conflicts.

So you could consider renaming --stash to --autostash. Or maybe rename and provide --stash as an alias (to avoid breaking changes).