-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Support preview Protected Branches API #934
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
Closed
+36
−19
Closed
Changes from all commits
Commits
Show all changes
5 commits
Select commit
Hold shift + click to select a range
b41e2dc
Get Branch Protection
scriptonist f867dc6
Added in missing comment, struct field
scriptonist 58b5a64
Changed the bits for all endpoints and tweaked tests
scriptonist 0120b56
added missing comment to mediatype and ran go generate
scriptonist e9b2196
Merge branch 'master' into Issue876
gmlewis File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Oops, something went wrong.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As written. the new
omitempty
tags aren't useful because the fields are not pointers and therefore can not benil
.But looking back at https://github.com/google/go-github/pull/637/files , I'm not seeing why these were not originally made to be pointers with the
omitempty
tag. Maybe @shurcooL remembers? I read through the comments but it looks like I didn't bring up this point before and neither did anyone else.Unless @shurcooL says otherwise, I'm thinking that these fields need to be turned into pointers and the
omitempty
tags should be added since these are return values.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm sorry I didn't get you. Should I make any changes or are we waiting for @shurcooL for a response?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's go ahead and change these fields to pointers and add
omitempty
since this struct is part of the return value.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gmlewis let me make sure I got It correct, you are suggesting that we add
omitempty
to the following structs, Right?https://github.com/scriptonist/go-github/blob/0120b56d9901fcafe451c9d08ea8f446478ce0d0/github/repos.go#L536
https://github.com/scriptonist/go-github/blob/0120b56d9901fcafe451c9d08ea8f446478ce0d0/github/repos.go#L544
https://github.com/scriptonist/go-github/blob/0120b56d9901fcafe451c9d08ea8f446478ce0d0/github/repos.go#L552
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the confusion. It looks like you have already added
omitempty
to all thePullRequestReviewsEnforcement
struct fields, which is what I was requesting.I'm thinking that to make the
omitempty
tags effective, we should also make all the fields pointers.So they would be:
Please let me know if that is not clear.
@jkosecki - maybe you can comment on what you think about these proposed changes since you authored #617?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This may be a noob question but why are we using pointers for types like
int
andbool
? @gmlewisThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is an excellent question, @scriptonist, and there have been several very good discussions about it. In a nutshell, it is so that we can tell if the server populated the field that it sent back to us which is especially important for variables like
bool
where you want to know if you are really getting back afalse
or if the server didn't send a value at all.It is actually more important on the request side than the response side, really... which is why they may not be needed at all in this situation. I think I'm contradicting what I said earlier, unfortunately, and apologize. I said "since this struct is part of the return value". That is not good enough reason to make this change, really...
So I'm thinking now, let's hold off on my most recent request to make these all pointers.
Especially if the docs seem to indicate that these fields will always be sent in the reply.
Hopefully @jkosecki or @shurcooL can provide a code review and then we can get this merged when they are also happy with the changes. As this stands, I'm going to give this my LGTM.
Thanks again, @scriptonist, for bearing with me.
Here is a search of some of the previous great discussions about using pointers in this repo:
https://github.com/google/go-github/issues?utf8=%E2%9C%93&q=is%3Aissue+pointers
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, @gmlewis for the detailed explanation. I was curious to know why things are like this. This was a perfect answer to that. I really appreciate your willingness to assist.