If you name it "git-jk" rather than "gitjk", you can invoke it as

  git jk

The gitjk command needs to operate as a shell alias though

Is that specific to git or is it in the shell?

All of the:

  git <command>

commands are executables of the form 'git-<command>' in specific directory:

  $ git --exec-path
  /usr/local/Cellar/git/1.9.0/libexec/git-core 

  $ ls $(git --exec-path) | head
  git
  git-add
  git-add--interactive
  git-am
  git-annotate
  git-apply
  git-archimport
  git-archive
  git-bisect
  git-bisect--helper

In git's earlier years, it was just a set of git-<command> commands in $PATH, until the master git command was created (to 'rule them all' if you will).

git will actually pick up anything in $PATH of the form 'git-<command>' and allow you to run it as 'git <command>'. The downside of this, is that commands of the form:

  git <command> --help

are intercepted by git and converted to:

  man git-<command>

So your command cannot process the --help option itself when called like this (or it used to be this way a couple of years ago).

Edit: Another downside, is that some 'smart' command-line completion settings either have a hard-coded list of 'git <command>' commands, or look for said commands in the value returned by 'git --exec-path'. So you can't tab-complete git-<command> commands that you just drop into $PATH (at least not out of the box).

It is specific to git.

Git.

I occasionally wish git had an undo-whatever-I-just-did command, and I've been using it for years.

The git fixup page comes in quite handy. https://sethrobertson.github.io/GitFixUm/fixup.html

Why is sudo hardcoded into so many commands? I'll run your program with privileges if it needs and earned them, thank you very much.

It will print (not run) the command unless you type 'gitjk -f'

When I run 'rm -r' on my machine it warns me about every file in the .git directory.

`sudo` is not the best practice with regard to removing that warning, try the `-f` flag instead.

I like how tame and polite your reply is.

Some days are worse than others. Some days I rage out. Other days I realise that some people just don't know something and the best practice is just to educate them rather than raise your blood pressure.

It really depends on how much coffee and sleep I've had. Thanks for the kind words.

Thanks! I've amended this in the current version

rm -rf?

It's kind of nice that this just gives suggestions by default rather than running potentially breaking commands.

But as someone else here mentioned, you really want to understand the reflog in git. Everyone screws up at some point or another, and it's much easier to work through things when you can rely on the reflog to act as a safety net and an anchor of sanity.

Adding it here: http://stackoverflow.com/questions/12589813/whats-a-single-g...

The git reflog gets you out of all kinds of messes. https://medium.com/git-tips/a4189dd88c40

I'm pretty sure your fetch logic is not right. First it assumes no arguments are passed. You assume origin/master (which is convention but not guaranteed) and also you assume a refspec isn't passed (in which case you need to rollback FETCH_HEAD).

See also

http://blog.kazuhooku.com/2014/04/announcing-unco-undo-chang...

If anyone wants a fish function:

    function jk
        history | head -n+10 | tail -r | gitjk_cmd
    end

Maybe git full undo via automatic snapshotting (branch/stash)? It's fine unless you hit a perf wall on huge repos.

Does it work if you call it 2x or more?

rebase isn't very hard to implement; you just have to check the reflog.

Uh... if you want to undo a git add shouldn't you be doing git reset?

somehow when I was testing it, I thought I needed to use rm -r --cached to remove a previously untracked file. It should do git reset in most cases.

Edit: now recommends git reset unless you did "git add ." or something like that.

You may have been on your initial commit; in that case, you need to use rm --cached instead of reset to undo a git add.

Isn't that what git reflog + reset are for?

It does rely on history? Well, it won't work for me then — in my history there's only frequently-used commands.

sudo hard-coded, and an intolerably stupid name. Next.

well it could be named git-unfuck (1)

Except going by the examples it actually just makes things worse by providing bad advice.

Such as?