GitHub pull requests actually are exposed as git objects (not the comments though, just the commits that make up the PR). If you want to see the commits in PR #515 you can just `git fetch origin pull/515/head`, or `git fetch origin pull/515/merge` to get the merge commit GitHub created when testing if your PR can be merged into the target branch.

Is this possible if the PR is coming from a fork?

It is.

To expand on this, you need to add the fork as an alternate remote (as opposed to origin), and then replace "origin" in the command posted prior.

So it's not possible from a fork, if you've only added the original repo as your single remote?

Currently I add the random person's fork as a remote to inspect/modify their PR branch. Was hoping for some GitHub magic to eliminate this step.

It is possible. You can specify a URL instead of a remote name for `git fetch`.

I thought it was in the PR destination repository (since they are under that repository's /pull namespace). You'd need to add the alternate remote if it's a PR into a fork (as opposed to from it), no?

You are absolutely correct. My apologies, as I understood the problem as "I have a fork and want to receive pull requests".

This can be a pretty common setup for some git workflows. Everybody makes a fork and takes / pushes pull requests or branches from their fork to others. The main advantage would be that if you have a lot of branches they don't all have to be on upstream and you don't need to have upstream permissions for everyone to push branches or changes to.

Nonetheless, I can see why my comment raised some confusion.

Have you seen https://github.com/google/git-appraise

Cool... haven't seen that. I guess what I'm asking for is for this stuff to become standardized. Once that happens if someone wants to write a web app around it that's fine, but it'd have to be run locally where the content can be decrypted and made sense of.

For another approach to managing API keys, secrets, and config with end-to-end encryption, check out EnvKey: https://www.envkey.com

Since it keeps secrets completely outside of git, you don't have to give up the convenience of collaboration tools by client-side encrypting the whole repository, and integration/deployment is simpler than maintaining a separate encrypted secrets repo.

Here's our Show HN from last week for more detail and discussion: https://news.ycombinator.com/item?id=15330757

Branches are Git objects. Incidentally, here's a distributed VCS that includes bug tracking: https://fossil-scm.org

No, branches are not git objects. An object is something that is identified by its sha1. Branches are merely files on the filesystem that point to objects.

You're thinking about branch names. The branch itself (anonymous branch?) is part of git because the commit history is a tree with branches.

It's part of git, but is not a git object, those have a very specific definition: it's all the thing that are identified by their hash.

Note that the commit history doesn't depend on branches: it's just a chain from commit to commits. The tree can exist withou any branch at all. That wouldn't be very useful, but it's still valid. Branches are merely pointers to a commit.

> Branches are Git objects

That's not how I understand refs, they don't even live in the .git/objects hierarchy.

You're correct, they're just files. To create a new branch off of master you can just...

  cp .git/refs/heads/master .git/refs/heads/WTFFF

... no SHA-1 involved at all, no parent, history, etc.

However what they point to are git objects. And being pointed to prevent them from being garbage collected (pruned).

I guess I don't understand what GitHub/GitLab does that makes branches different from Git itself (which seemed to be the claim I was replying to).

Thanks for replying, I understand your position better now.

> I guess I don't understand what GitHub/GitLab does that makes branches different from Git itself [in the GP]

The GP is mistaken. Their understanding of objects & refs seems different to how I've seen them refered to in the majority of git literature.

For passing readers: refs (branches and tags) are just git's way of labelling a commit (which are stored as objects). GitLab/GitHub don't do anything special to implement refs: they're standard git refs. They're not different, they're 100% part of git.

GitHub/GitLab do add a lot of extra refs to track things like PR/MRs.

> Branches, pull requests, comments, etc... should all be Git objects of some sort.

Branches can't be objects because you'd need a way to find them with a label, and then why not use the labels directly instead?

PRs and comments can be stored in a repo (as refs and notes), but git doen't have a strongly-opinionated view on the exact workflow you should follow when developing, and thus isn't interested in recommending that people should always use forks & CRs.

Right, there's no PRs/MRs in Git itself, but branches are there, specifically in that there's nothing about the existence of or use of branches in GitHub/GitLab that needs to be brought back into Git, that stuff is already there.

I recognize and accept the argument that it might be nice for Git to track merge-requests and issues (hence my link to Fossil SCM)

Somebody else said branches were already native to git. So are pull requests. Comments and issues are unlikely to be made native to git ever since git is developed primarily for the Linux kernel and their discussion channel is the mailing list.

Everyone should have been collaborating through distributed code review pushed into repo branches. Take a look at how SmartGit does it

It could be used for storing/fetching secrets and managing access for teams of real/application users.