New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

GitHub API questions #94

Open
scripting opened this Issue Sep 11, 2018 · 5 comments

Comments

Projects
None yet
3 participants
@scripting
Owner

scripting commented Sep 11, 2018

TL;DR -- How to find the root of a repo for the tree api, and are the content and tree APIs deprecated as of Oct 1?

  1. I'm using the contents API to do a traversal of the directory structure of a repository. It works. Here's a gist containing the code. It takes about three seconds to traverse the structure of my test1 repo. I'm thinking about using the tree API, hoping that it will be considerably faster. But I can't figure out how to get the sha for the root of the repo. Any suggestions much appreciated.

  2. There are notes on the GitHub API website about GitHub Services being deprecated starting October 1. At first I thought this applied to the API I'm using. Now I'm wondering. I'm just using the contents API. Is this part of the deprecated set? If so arrrrgh. And where can I find good sample code for getting and setting the contents of a file and doing a directory traversal.

@deltab

This comment has been minimized.

Show comment
Hide comment
@deltab

deltab Sep 14, 2018

  1. It seems that in place of a hash you can give any 'tree-ish' expression that git can resolve, including commits, branches and HEAD, and even their subdirectories:

    And yes, it is considerably faster.

    (If you couldn't do that, you could fall back on getting the repo's refs (branch heads), finding the master branch, getting its latest commit, and getting the tree from that. But that'd take multiple requests.)

  2. Nothing to do with the REST API you're using:

    GitHub Services (sometimes referred to as Service Hooks) is the legacy method of integrating where GitHub hosted a portion of our integrator’s services via the github-services repository. Actions performed on GitHub trigger these services, and you can use these services to trigger actions outside of GitHub.

    So if you wanted to send a notification to a chat channel when someone pushed a commit, or to run automated tests, or rebuild a static website, you could put some Ruby code here and GitHub would run it to trigger processes elsewhere.

    They've decided that they want to do it more consistently in future: they'll instead send HTTP requests to a URL of your choice, and you're responsible for making things happen from there.

deltab commented Sep 14, 2018

  1. It seems that in place of a hash you can give any 'tree-ish' expression that git can resolve, including commits, branches and HEAD, and even their subdirectories:

    And yes, it is considerably faster.

    (If you couldn't do that, you could fall back on getting the repo's refs (branch heads), finding the master branch, getting its latest commit, and getting the tree from that. But that'd take multiple requests.)

  2. Nothing to do with the REST API you're using:

    GitHub Services (sometimes referred to as Service Hooks) is the legacy method of integrating where GitHub hosted a portion of our integrator’s services via the github-services repository. Actions performed on GitHub trigger these services, and you can use these services to trigger actions outside of GitHub.

    So if you wanted to send a notification to a chat channel when someone pushed a commit, or to run automated tests, or rebuild a static website, you could put some Ruby code here and GitHub would run it to trigger processes elsewhere.

    They've decided that they want to do it more consistently in future: they'll instead send HTTP requests to a URL of your choice, and you're responsible for making things happen from there.

@scripting

This comment has been minimized.

Show comment
Hide comment
@scripting

scripting Sep 14, 2018

Owner

First, thanks for the answers to both of the queries.

To the first one, your first call definitely returns a list of all the files in the repo. But I'm not familiar with the term HEAD. I assume that must come from the GIT world?

What does it mean? Is it documented somewhere? I'm happy to read, and scratch my head. I have a feeling if I understood that nomenclature I'd do a lot better with their API. ;-)

Thanks again.

Owner

scripting commented Sep 14, 2018

First, thanks for the answers to both of the queries.

To the first one, your first call definitely returns a list of all the files in the repo. But I'm not familiar with the term HEAD. I assume that must come from the GIT world?

What does it mean? Is it documented somewhere? I'm happy to read, and scratch my head. I have a feeling if I understood that nomenclature I'd do a lot better with their API. ;-)

Thanks again.

@rosskarchner

This comment has been minimized.

Show comment
Hide comment
@rosskarchner

rosskarchner Sep 14, 2018

I think you can understand HEAD as an alias to the latest commit in the branch you have checked out. In a clone of this repo, checked out to the master branch, HEAD would be a synonym for d342e07

I've been using git for years, and still found these episodes of All Things Git helpful:

https://www.allthingsgit.com/episodes/branching_and_merging_part_1.html
https://www.allthingsgit.com/episodes/branching_and_merging_part_2.html

rosskarchner commented Sep 14, 2018

I think you can understand HEAD as an alias to the latest commit in the branch you have checked out. In a clone of this repo, checked out to the master branch, HEAD would be a synonym for d342e07

I've been using git for years, and still found these episodes of All Things Git helpful:

https://www.allthingsgit.com/episodes/branching_and_merging_part_1.html
https://www.allthingsgit.com/episodes/branching_and_merging_part_2.html

@scripting

This comment has been minimized.

Show comment
Hide comment
@scripting

scripting Sep 14, 2018

Owner

I need to explain what the app is, because it actually isn't about GIT, it's about a repo being used to host a blog. I want a way to get a list of all the editable files in the repository, so I can present them to the user in the equivalent of an open file dialog.

So if HEAD is an okay way to do that, then I'll use that. Assume that there are never any branches in the project. The repository is functioning like a file system.

I'm also okay with using the code I have that does its own recursive traversal of the repo. It turns out to be fast enough, even with a pretty active blog over a bit of time.

Owner

scripting commented Sep 14, 2018

I need to explain what the app is, because it actually isn't about GIT, it's about a repo being used to host a blog. I want a way to get a list of all the editable files in the repository, so I can present them to the user in the equivalent of an open file dialog.

So if HEAD is an okay way to do that, then I'll use that. Assume that there are never any branches in the project. The repository is functioning like a file system.

I'm also okay with using the code I have that does its own recursive traversal of the repo. It turns out to be fast enough, even with a pretty active blog over a bit of time.

@deltab

This comment has been minimized.

Show comment
Hide comment
@deltab

deltab Sep 14, 2018

Assume that there are never any branches in the project.

Using git's terminology, there's always at least one 'branch' in a repo; it's called master by default. If you look in the top left of https://github.com/scripting/test1 you'll see a button "Branch: master". You can use that to switch to other branches, if you happen to have any. HEAD is (in part) the command-line equivalent of that selector.

You can use the branch name in URLs, and it's probably better to do so:

GitHub rate-limits API requests, so it's better to reduce the number sent when you can. (Also, why do more than you need to?)

deltab commented Sep 14, 2018

Assume that there are never any branches in the project.

Using git's terminology, there's always at least one 'branch' in a repo; it's called master by default. If you look in the top left of https://github.com/scripting/test1 you'll see a button "Branch: master". You can use that to switch to other branches, if you happen to have any. HEAD is (in part) the command-line equivalent of that selector.

You can use the branch name in URLs, and it's probably better to do so:

GitHub rate-limits API requests, so it's better to reduce the number sent when you can. (Also, why do more than you need to?)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment