Hub: Provide a way to ignore hub's aliases

[grimreaper]

I have my own "git sync" alias which does the right thing in my environment. Unfortunately hub recently introduced a "hub sync" command which does things I don't want (deletes branches, doesn't pull). Additionally, as noted in a below comment, it may even result in data-loss. I can't seem to find a way to make use of hub as a proper around git without having its sync get in the way. One option is to introduce yet another wrapper that dispatches to either "git" or "hub" depending on the command provided, though this would require more intimate knowledge of git's command line parsing.

The best way I forward I could think of is to do one of the following:

(a) ensure that git aliases override hub's commands.
(b) provide a way to bypass hub's commands per-command.

Obviously I'm open to other solution that solve my problem.

[grimreaper]

A similar issue exists with hub's new "hub pr" command which conflicts with locally defined aliases (that are mostly unrelated to github). It would be ideal if hub would use a longer less conflicting name, and let users alias shorter names if they prefer.

[grimreaper]

Sorry for spamming this ticket but I just noticed particularly dangerous behavior on the part of "hub sync":

If a local branch doesn`t have any upstream configuration, but has a
same-named branch on the remote, treat that as its upstream branch.

this is nearly always wrong in my environment and might result in severe confusion and possible data-loss only recoverable via the reflog.

there must be some way to ensure that hub's idea "sync" never executes.

[mislav]

• Commands shadowing aliases: it's core git behavior https://github.com/github/hub/issues/1536#issuecomment-395212948.
• this is nearly always wrong in my environment — possibly, but hub will only ever delete a branch if it had upstream configuration _and_ the upstream branch has been deleted (i.e. its remote tracking branch disappeared) _and_ the head of the local branch has been merged into the default branch. Can you elaborate a bit more on how you see possible data loss happening? Did data loss actually happen to you which you had to restore using reflog?
• there must be some way to ensure that hub's idea "sync" never executes. — there is an easy way: don't run hub sync.
• What are your full expectations of what hub sync command would do? I'm soliciting feature feedback.

[grimreaper]

Meta point: one thing that I liked about hub, unlike most other git extensions, is that it was a really lightweight wrapper around git. It basically didn't do anything or bother me unless I was explicitly trying to work with github. Other utilities like "git-extend", "git-extras", and so on added so many commands that it was impossible to know what even making a typo would do.

What are your full expectations of what hub sync command would do?

To my meta-point: ideally not exist. It isn't github specific.
If you want to replicate roughly what I have it do, do in order, and only if the previous step was successful:

• run git fetch
• attempt to use my branch's default (merge/rebase) to update from the tracking branch
• push to the upstream branch (based on push.default)
• run git submodule update --init --recursive

Right now that's 'sync' is aliased to '!git pull && git push && git submodule update --init --recursive' though I've changed that configuration locally over time.

Only ever delete a branch if it had upstream configuration and the upstream branch has been deleted.

This isn't what was documented. In this case, it does more than I want it to, but isn't as dangerous as I understood. I was worried about the case where it had no upstream configuration, but the remote branch happen to have had the same name.

there must be some way to ensure that hub's idea "sync" never executes. — there is an easy way: don't run hub sync.

I should clarify: "... while still making use of the rest of hub's features".

Commands shadowing aliases: it's core git behavior #1536 (comment).

Hrm... that's annoying though not hub's fault. This wasn't a problem when hub only had some long commands that rarely clashed [0]. Unfortunately with the shorter names, and broader scope (git sync has nothing to do with github) we're running into issues. While the ideal solution is for git to provide better control over what it does, one workaround is for hub to provide per-command control to make it a passthrough.

[0] I am aware of some shadowing behavior for even simple commands like "git clone" to make it easier to checkout github repos. This is nice, and has never caused me problems.

To summarize I think we should do one of the following, not in any specific order of "goodness":

(A) use only longer non-clashing names.
(B) option A, but also provide default aliases to shorter names. This makes them overridable
(C) Provide a hub-specific configuration to make commands pass-through rather than actions.

(P.S. thanks for all your work. I've been using hub for years now, and never noticed it until today. That's a good sign!)

[mislav]

Thank you for your thoughts!

I had this idea for hub for a long time: even when aliased as git, hub-specific commands like hub create, hub pr, hub sync and others should only be available when the command is invoked as hub and not as git. These subcomands would be unavailable by design when typing git sync, git pr, etc., leaving room for aliases.

To achieve this, we would have to give different instructions for our users than doing alias git=hub, because aliases implemented by the shell don't give us a distiction whether a command was invoked through an alias or not.

[docwhat]

Having all commands available as hub makes sense. Having hub override things provided via commands (e.g. git-extra's git-pr) or by a user's aliases seems confusing and not a good user experience.

Doing this automatically would be nice. But being able to turn off certain commands when used via git (instead of hub) would be sufficient.

[grimreaper]

Somewhat related, though probably worth a different issue, is that hub does not follow git's configuration for spell correction. For example:

∴git pull-reqst
git: 'pull-reqst' is not a git command. See 'git --help'.

but

∴git psh
WARNING: You called a Git command named 'psh', which does not exist.
Continuing under the assumption that you meant 'push'.

[alvaropinot]

Hey @grimreaper I just opened #2219 about spell correction. Commenting here to get them linked 😃

Somewhat related, though probably worth a different issue, is that hub does not follow git's configuration for spell correction. For example:

∴git pull-reqst
git: 'pull-reqst' is not a git command. See 'git --help'.

but

∴git psh
WARNING: You called a Git command named 'psh', which does not exist.
Continuing under the assumption that you meant 'push'.

[Arnie97]

The hub pr command really makes me confusing, since we already have hub pull-request here, with a similar name but different function. Btw I prefer pr = pull --rebase, and hub pr breaks my alias.

[alvaropinot]

Yep @Arnie97 I have the same feeling, not about pull rebase but just having two commands to interact with PR's confuses me 😅