bash-it

bash-it copied to clipboard

Git can list local branches, remote branches, and both of them together. Let's use the long form of the options to make the aliases quicker to understand.

Motivation and Context

Listing remote branches was missing from the git branch aliases.

How Has This Been Tested?

Not directly from this source code, but I used the aliases before on my local developer machine.

Types of changes

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

Checklist:

• [x] My code follows the code style of this project.
• [x] If my change requires a change to the documentation, I have updated the documentation accordingly.
• [x] I have read the CONTRIBUTING document.
• [x] 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.

So I vote that we lose the gba and gbr

Agreed.

I just noted that gbl does the same as gb and that in other implementations (e.g. OMZ) it is assigned to git blame.

Hence, we may also let go of gbl in favor of just gb. gblr and gbla may stay there for the sake of unambiguity.

In fact I prefer the gbl* variants as they seem more clear to me and also give the option of providing glob patterns to match against.

Also gbr could be mistaken as an alias for git branch and ppl might find it confusing in practice.

I think we're getting closing in understanding the ambiguity.

Since gb is already git branch and gbr is only the "remote" version of it, developers will learn quickly to rewire their muscle memory in case they use gbr. No real harm should happen from this.

With gbl (as a prefix) this is different. If we follow the concept of having a common prefix for all commands, and this prefix is gb in our case, and we may want to use gbl for blame, and we're able to let go of gbl for branch --list, then we would come back to the solution of the shorter aliases gba and gbr (for --all and --remote).

I would suggest to then introduce gbl as an alias for git blame, directly. – What do you think?

Soo ..

I never use git blame from cli, but I use the gbl alias to list branches regularly.

gb is of course very special since, as the naked git branch alias, users can use it as the base for any git branch commands ... Yes it prints a list by default, however ...

gbl has the benefit in that you can supply a <pattern> argument, which is only allowed when you also provide the --list argument.

If we see any value in the gbla and gblr aliases, then gbl must have similar value.

It would also be awkward to have gbl be git blame but have gbla and gblr be branch related.

For bash-it, I think gb* is generally best used for git branch based aliases.

That said, I could see a potential for a gblame alias, as I think that would be non-ambiguous and still somewhat useful.

I also think its trivial for users to override aliases in their .bashrc (I override several) and some users (yourself included) will likely override gbl for git blame

Our goal to reduce all commands to 2-5 characters, by nature, can never please everyone, but I'm glad to have discussions like these.

Okay, then let's merge the current state of changes.

So I vote that we lose the gba and gbr

Agreed.

I think we're close, but looks like this change hasn't been made yet?

I think we're close, but looks like this change hasn't been made yet?

Done.

I am not sure about dropping gba. Although I am not using it at all, some people could still be using it and dropping support for it would only bring confusion. I think we should drop aliases only if they are clashing with some other programs, and dropping an alias just because you feel its clunky isnt a correct approach.

What do you think @bittner @davidpfarrell ?

I am not sure about dropping gba.

The decision to drop it came from the following discussion above:

Looking into the man pages more, gba and gbr both result in lists, and I don't think they bring enough value over the gbl* variants.

I too would argue that I'd naturally use gba and gbr (albeit mostly the latter), and may find myself confused not having them around. I'm confident that I'll get used to the idea of "branch list", but new users may not conclude this naturally.

Said that, I'd be happy to re-add both variants. Since gbla and gblr provide additional value I think all 4 could stay.

I am not sure about dropping gba.

The decision to drop it came from the following discussion above:

Looking into the man pages more, gba and gbr both result in lists, and I don't think they bring enough value over the gbl* variants.

I too would argue that I'd naturally use gba and gbr (albeit mostly the latter), and may find myself confused not having them around. I'm confident that I'll get used to the idea of "branch list", but new users may not conclude this naturally.

Said that, I'd be happy to re-add both variants. Since gbla and gblr provide additional value I think all 4 could stay.

I am completely fine with adding new variants, but old variants should not be dropped so lightly IMO

I am not sure about dropping gba

I'm fine leaving it in - I prefer to remove it, but I see your point ...

I prefer to learn patterns. Rules that I can apply and that work out in a generic way. So, while I'll be re-adding gba I'll also re-add gbr – because we have gbla and gblr. It will make the pattern (more) complete.

I hope that's fine for you folks.

If that resolves all discussions I'd be happy to see the change merged! :100:

Afterwards, I'd immediately dedicate myself to resolve #2160 (as this is slightly related and touches the same source file).

Something's broken with bats on macOS 11. Not sure what is is, really:

# bats warning: Executed 245 instead of expected 268 tests
Error: Process completed with exit code 1.

Something's broken with bats on macOS 11. Not sure what is is, really:

# bats warning: Executed 245 instead of expected 268 tests
Error: Process completed with exit code 1.

There is something statistical in macos tests, this is unrelated to you

Thanks @bittner and @davidpfarrell for the review!