hub works just fine to create a PR, some lack of RTFM is at play.

So, I never trust users to give me advice on features to add.

But I always believe them when they say something is difficult or confusing. Research should not be required to make a good CLI do what you want, provided you understand what you want.

Might like http://blog.codinghorror.com/listen-to-your-community-but-do...

What you needed was to use the options -h (head, ie. the feature branch) and -b (base, ie the upstream master) eg.

    git pull-request \
      -m "I added an awesome feature"\
      -b baserepo:master\
      -h myfork:feature-branch

The GitHub web interface defaults to the PR-to-upstream behavior though, so this is at least an inconsistency; I would argue it is a bug.

> All this press-ctrl-with-your-palms fad is a problem solved in the wrong place.

Total agreement from me, I consign this piece of advice to the same trash pile as !!NEVER USE ARROW KEYS!! ... cargo-culting nonsense.

There's a lot of power hidden away.

Interactive rebase/squash is tough to find... so here it is.

in Magit status, do l l (log, short-log)

Select the sha1/commit you want to begin squash/pick rebasing...

press E

off you go.

It's a little un-intuitive.

Adding git-gutter to the mix will allow staging / reverting at the hunk level.

I should probably note also that in Magit status, the user has to TAB the unstaged file to be able to do region or hunk level staging.

Ideally it would be possible to do it in the buffer in question as well.

Not even git-gutter has region style staging. Hopefully it will be implemented soon. I had a crack at it but time got away from me.

Thank you for this - git-gutter looks awesome. I wasn't aware of staging hunks too so I've learned about 2 things :)

That just sounds silly.

you mean like this?

http://i.imgur.com/evUJkAv.jpg

You misunderstand.

The repo you're referring to is Railwaycat's mirror of Yamamoto Mitsuharu's codebase. (which previously was only available via ftp and tarballs.)

Yamamoto has recently migrated to git and hosts a repo at Chiba U, the address is: http://www.math.s.chiba-u.ac.jp/~mituharu/emacs-mac.git

HOWEVER. Railwaycat does still maintain the Homebrew tap and formula for installing Emacs Mac Port

Here: https://github.com/railwaycat/homebrew-emacsmacport

A simple install via:

   brew tap railwaycat/emacsmacport
   brew update
   brew install emacs-mac

And you have a far superior Emacs for OSX than that built by emacsformacosx.com.

Once built, you can (without any problems) move the Emacs.app into your /Applications/ folder.

Don't do yourself a disservice, install Emacs Mac Port now.

So what is the benefit compared to the emacs port 'emacs'?

I found a full listing here: https://github.com/railwaycat/emacs-mac-port/blob/master/REA...

Thanks! Most of it was meh, but some sounds really good. The homebrew version provides hdr gfx but not all of this.

It's easy to misunderstand because it's not clear at all what is and isn't mirrored.

Quite, pretty much zero supporting evidence.

Seems to have 404'd