Support inline expansion of Git abbreviations

[henrebotha]

The existing Git alias functionality generates global abbreviations prefixed with "g". This is not ideal as it can clobber many other commands or aliases.

This commit introduces functionality that allows for inline expansion of Git abbreviations, provided they are typed on a line that starts with the word "git".

It introduces a --git flag, analogous to the --global flag, that can be used to add a Git abbreviation.

Resolves #32.

[henrebotha]

This doesn't actually work correctly yet; it still expands when the command starts with something other than git. Working on it!

[olets]

Interesting. Before you sink too much time into it, can you explain the use case?

I'm excited to see what you do but heads up this week's really busy so I may be slow to respond.

[edit: I personally drop the g whenever I can — e.g. abbr s="git status". The original idea of the import was to make it easer for people who are heavily invested in Git aliases to move to abbr, not necessarily to generate final abbreviations. My initial thought is supporting a word prefix goes against to "get rid of every avoidable keystroke" philosophy. Still… very interesting]

[henrebotha]

No worries, whenever you have time.

The use case for me is: Just like I never want to type git when g will suffice, I want to be able to use my extensive suite of Git aliases instead of typing their full equivalents. Given a regular command alias g=git, typing g<space>s<enter> expands to git status --short and accepts it. Of course, I could simply have a command alias gs, which even accomplishes the same thing with one fewer keystroke; but then I run into the problem of colliding with other commands. (For example, I frequently have to make use of a command gp at work, which precludes having an alias such as gp='git pull'.) Having the ability to force an abbreviation to start with a particular prefix means I can "scope" all my Git aliases under a "namespace", and then go nuts with defining any Git aliases I want without having to worry about them potentially colliding with some command that just happens to start with "g".

---

It looks like it behaves now w.r.t. non-git commands. Still missing:

• [ ] The ability to abbr expand Git abbreviations.
• [ ] The ability to erase Git abbreviations.
• [ ] The ability to rename Git abbreviations.
• [ ] Updated Readme.

[olets]

(And sorry for the crossed wires, missed the issue you opened. Between that and my ps confusion I think my head must be too much in other places to think about this before the weekend 👍)

[olets]

Let's continue the broader convo over to #32 (no rush on a reply though)

[olets]

Closing in favor of possibly supporting multi-word command-position abbreviations, see 32 for discussion. Cool stuff tho!