How to compare local branches in github from a forked repo?

Question

By "local" I don't mean local to the development machine. I mean when you are logged into GitHub, the branches directly in the repository you have navigated to as opposed to the ones in the repository you forked from.

So I have access to a user's repository that was forked from another user's repository which I do not have access to.

When I create a branch on this user's repository, sometimes I want to compare with the default branch on the SAME repository (the one I have access to). However, it always defaults to compare to the upstream repository which produces a 404 because I don't have access to that one.

So then I use the "compare across forks" link. This was soooo confusing for the longest time because the drop down would show the account/repo that I wanted AND when I clicked the drop down it was also the one that was checked. Yet I couldn't find my branch in the next drop down. I've finally figured out that GitHub is lying to me. Even though it says the account/repo I want is already selected; it's not. It's really got the upstream account/repo selected. So now I know I have to actually click on the correct one (that's already allegedly selected; but not really). Then it takes me to a page where I can select my branch and do the comparison I originally wanted.

So to recap here is what I have to do:

1. From the repo page with the default branch selected, click the Compare link
2. Click the compare across forks link.
3. Select the account/repo I want from the drop down (which is already selected; but not really)
4. Select the InsiderCharts branch from the base drop down.

I'm fairly new to Git, so I'm trying to figure out if I am somehow approaching this wrong and should be doing it a different way... or is this just a terrible bug in GitHub that makes life miserable for new users already having trouble figuring the darn thing out?

I have to say I am not a fan of Git. I'd love to rant further about my frustration here... but I suppose I'll spare you since this isn't really the place for that. :)

Answer 1

So then I use the "compare across forks" link. This was soooo confusing for the longest time because the drop down would show the account/repo that I wanted AND when I clicked the drop down it was also the one that was checked. Yet I couldn't find my branch in the next drop down. I've finally figured out that GitHub is lying to me.

It's important to realize that some things are Git, and some things are specifically GitHub. Forks—at least, the way GitHub implements them—are specific to GitHub. All Git has are clones.

So: what's the difference between a clone, and a fork? There are a bunch of small differences, but the number one thing is that while a fork is a clone, a clone is not a fork. A fork is a clone with extra features, such as "pull requests" (and of course "compare across forks"). Everything you're asking about here is one of those extra features.

As for why GitHub is lying to you: in this particular case, I don't know. In the most general cases, sometimes they kind of have to, because some things in some repositories are restricted or private. You'll get a clone, and all the clone parts work because they are handled directly by Git itself, and then someone will change something about the repository you cloned, and the add-on features will break.

I generally try to avoid the GitHub web interface for most uses. If I have a GitHub repository G that is a GitHub fork of "upstream" GitHub repository U, I'll keep a truly-local Git repository—my own clone, on my own computers—and use origin to refer to repository G from my computer, and use upstream—or some better name, since I have to assign it myself, vs origin which Git made for me on is own when I ran git clone—to refer to repository U from my computer.

To do the equivalent of "compare across forks" I just fetch from both origin and upstream (or whatever name it might have). I then have all the commits, locally, on my own computer, where I can compare them locally, view them locally, and so on.

This is the one place where git fetch --all is actually useful: --all means fetch from all remotes. In this case, that's origin and upstream both. Note, though, that if you start getting into these more complex cases—especially those with more than just two additional repositories—you might want to look into using git remote update and/or defining remote groups. There is a lot of stuff in Git to handle these unusual cases, that most people never need to worry about.