Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

aliases: Add new git-omz alias file #1831

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

NoahGorny
Copy link
Member

Description

Adds git-zsh alias file, with aliases copied from ohmyzsh.
Currently there is no simple way of updating the aliases easily, and maybe we need to think about it.

Motivation and Context

Prompted by #1191, this is a re-iteration of #1201.

How Has This Been Tested?

Locally

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • My code follows the code style of this project.
  • If my change requires a change to the documentation, I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • If I have added a new file, I also added it to clean_files.txt and formatted it using lint_clean_files.sh.
  • I have added tests to cover my changes, and all the new and existing tests pass.

@cornfeedhobo
Copy link
Member

Anyone else torn on whether we should use zsh-<whatever> vs <whatever>-zsh?

@NoahGorny
Copy link
Member Author

Anyone else torn on whether we should use zsh-<whatever> vs <whatever>-zsh?

I went with git-zsh as I wanted to keep it close to the git alias, it makes more sense this way IMO

@NoahGorny
Copy link
Member Author

Hey @bittner, wanna take a look?

@bittner
Copy link
Contributor

bittner commented Feb 13, 2021

How will we keep this aligned with the Oh My Zsh project implementation?

In PR #1201 I tried to document a scripted approach. Would it make sense to do something similar here?

@NoahGorny
Copy link
Member Author

How will we keep this aligned with the Oh My Zsh project implementation?

In PR #1201 I tried to document a scripted approach. Would it make sense to do something similar here?

This is indeed a problem, as the plugin will not work right out of the box..
Simply seding the file will still not work, as the aliases sometimes use the $(git_current_branch) variable.
We might vendor it, and add a file in init.d vendor directory which explains how to update, and also defines the needed functions. It will be maintained by us, and when we update, we will change the file if necessary.

The workflow might be git-vendor + removing uneeded file + seding the wanted file + adding git-zsh loader that defines the needed functions and load the wanted file

@bittner
Copy link
Contributor

bittner commented Feb 13, 2021

How many approvals does a PR need? 🤪

@NoahGorny
Copy link
Member Author

How may approvals does a PR need? 🤪

haha, I still need to add some kind of script that updates this completion.. so its not ready yet.
thanks for the CR though @bittner

@NoahGorny
Copy link
Member Author

I am also okay with vendoring it as it is right now- and update it once in a while. what do you think @cornfeedhobo @bittner ?

@gaelicWizard
Copy link
Contributor

May I suggest that the new alias file be named git-omz? It's providing aliases from Oh My Zsh, not from Zsh itself. Just a nitpick... 😆

@NoahGorny NoahGorny changed the title aliases: Add new git-zsh alias file aliases: Add new git-omz alias file Aug 14, 2021
@NoahGorny
Copy link
Member Author

May I suggest that the new alias file be named git-omz? It's providing aliases from Oh My Zsh, not from Zsh itself. Just a nitpick...

Nice idea- done!

Noah Gorny added 2 commits September 17, 2021 14:45
git-vendor-name: ohmyzsh
git-vendor-dir: vendor/github.com/ohmyzsh/ohmyzsh
git-vendor-repository: https://github.com/ohmyzsh/ohmyzsh.git
git-vendor-ref: master
@NoahGorny
Copy link
Member Author

Howdy folks!
I have added ohmyzsh as a vendored library using git-vendor with @buhl changes. this will hopefully be easier to maintain, although I still changed some code from the plugin so it will be loaded successfully
let me know what you think @cornfeedhobo @bittner @gaelicWizard

@cornfeedhobo
Copy link
Member

cornfeedhobo commented Sep 19, 2021

@NoahGorny I like it. The only question I have remaining is if you are open to the idea of applying patches to vendored libs and what that should look like. I still need to submit a patch to deal with pre-exec's clobbering of ignoreboth and ignorespace, and in the case of this PR, I'd rather not pollute the global namespace with the vaguely named is-at-least function.

@gaelicWizard
Copy link
Contributor

gaelicWizard commented Sep 19, 2021

The only question I have remaining is if you are open to the idea of applying patches to vendored libs and what that should look like. I still need to submit a patch to deal with pre-exec's clobbering of ignoreboth and ignorespace, and in the case of this PR, I'd rather not pollute the global namespace with the vaguely named is-at-least function.

@cornfeedhobo, I've already submitted a PR upstream for preexec's history shenanigans, based on an existing PR that they had been ignoring. They did accept an unrelated PR for unbound parameters, but no traction on this one yet.

As for weird function names, we can handle that in our loader. I'll give it a go and post it here later tonight.

I'd like to suggest that it's quite valuable to avoid, whenever possible, carrying any patches over vendor'd libs. I like Homebrew's stance on this: only carry patches that are already approved or merged in an upstream dev branch. But, that said, it might not be entirely right for Bash It.

@cornfeedhobo
Copy link
Member

cornfeedhobo commented Sep 19, 2021

@gaelicWizard I think you saw my open issue with preexec. They aren't going to budge on this one. We either maintain a fork in our github organization, and patch that way, or figure out a scheme for patching on PR and documenting the diff.

@gaelicWizard
Copy link
Contributor

@cornfeedhobo, I did a whole PR which keeps their desired behavior in place, but behaves properly when we change it. My idea was to let them have their way, and then we just set $HISTCONTROL back after we load them.

@NoahGorny
Copy link
Member Author

@NoahGorny I like it. The only question I have remaining is if you are open to the idea of applying patches to vendored libs and what that should look like. I still need to submit a patch to deal with pre-exec's clobbering of ignoreboth and ignorespace, and in the case of this PR, I'd rather not pollute the global namespace with the vaguely named is-at-least function.

The problem with patches is that we need to apply them somewhere, probably during installation. We need to think about how we do this and how other places are doing it. Simply having patches around isn't going to cut it sadly. I also think that committing directly into the vendored file like I did isn't great, but it is the simplest solution currently

@@ -2,6 +2,9 @@
cite 'about-alias'
about-alias 'common git abbreviations'

# We can use this variable to make sure that we don't accidentally clash with git-zsh aliases
_bash_it_git_aliases_enabled=true
Copy link
Contributor

@gaelicWizard gaelicWizard Jan 4, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you use _bash-it-component-item-is-enabled()?

Suggested change
_bash_it_git_aliases_enabled=true
if _bash-it-component-item-is-enabled aliases git-omz; then
_log_warning "The aliases from 'git' and from 'git-omz' conflict with each other; please only enable one."
return 1
fi

assert_line -n 0 -p ' aliases:'
for alias in 'git' 'gitsvn' 'git-omz'
do
echo $alias
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't the echo defeat the test?

@@ -0,0 +1,33 @@
# shellcheck shell=bash
cite 'about-alias'
Copy link
Contributor

@gaelicWizard gaelicWizard Jan 4, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't need this cite; "about-alias" is cited in bash_it.sh, so it never needs to be added to the alias files.

Comment on lines +5 to +8
if [[ -n $_bash_it_git_aliases_enabled ]]; then
_log_error "git-omz aliases are incompatible with regular git aliases"
return
fi
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if [[ -n $_bash_it_git_aliases_enabled ]]; then
_log_error "git-omz aliases are incompatible with regular git aliases"
return
fi
if _bash-it-component-item-is-enabled aliases git; then
_log_warning "git-omz aliases are incompatible with regular git aliases"
return 1
fi

Copy link
Contributor

@gaelicWizard gaelicWizard left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added suggested use of _bash-it-component-item-is-enabled aliases git. I think GitHub just lets you click accept if you like it and it commits it directly to the PR

@samtsevich
Copy link

Hello all,
Is there any news about merging these changes into master?

@bittner
Copy link
Contributor

bittner commented Sep 22, 2023

@NoahGorny Would you have a minute to resolve the conflicts of the PR and merge it, finally?

That would be great! 💯

@samtsevich
Copy link

Hello again :)
I asked this question a year ago and still would like to see this implementation merged into master.
Is there any chance of seeing this in the near future?

@seefood seefood added seems abandoned rattle the cage, and close if nobody wants to keep it going waiting-for-response labels Nov 7, 2024
Copy link
Contributor

@seefood seefood left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is close to perfect.
@NoahGorny shall I merge it as is or do you want to give it the last round of improvements per the remarks posted?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
seems abandoned rattle the cage, and close if nobody wants to keep it going waiting-for-response
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants