Skip to content

Add support for Commit Search endpoint #520

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
wants to merge 8 commits into from

Conversation

sahildua2305
Copy link
Member

@sahildua2305 sahildua2305 commented Jan 17, 2017

Added support for this new preview endpoint which lets users
search for commits based on various conditions.

GitHub announcement -
https://developer.github.com/changes/2017-01-05-commit-search-api/
Docs - https://developer.github.com/v3/search/#search-commits

Fixes #508.

\cc @shurcooL @gmlewis

github/search.go Outdated
AuthorName *string `json:"author_name,omitempty"`
AuthorEmail *string `json:"author_email,omitempty"`
AuthorDate *string `json:"author_date,omitempty"`
CommitterID int `json:"committer_id,omitempty"`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any reason these two ints (AuthorID and CommitterID) aren't pointers, like everywhere else?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops! No, that's a bug, not a feature.

github/search.go Outdated
@@ -54,6 +55,36 @@ func (s *SearchService) Repositories(query string, opt *SearchOptions) (*Reposit
return result, resp, err
}

type SingleCommitResult struct {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

golint issue here, exported struct SingleCommitResult should have documentation.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

@sahildua2305
Copy link
Member Author

@shurcooL can you please review again? 🙂

Copy link
Member

@dmitshur dmitshur left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found a few opportunities to improve, and asked a few questions.

@@ -150,6 +182,11 @@ func (s *SearchService) search(searchType string, query string, opt *SearchOptio
return nil, err
Copy link
Member

@dmitshur dmitshur Jan 19, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Update the documentation for this method. It currently says:

// ...
// GitHub search types (repositories, code, issues, users)

But that's no longer true after your change, there's one more.

github/search.go Outdated
if searchType == "commits" {
// Accept header for search commits preview endpoint
req.Header.Set("Accept", mediaTypeCommitSearchPreview)
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Combine this if statement with the if opt != nil && opt.TextMatch { below. They both decide what Accept header to set, and I think it should be exclusive (i.e., it doesn't make sense to think about the case where both run, since the second one would override the first one anyway).

A switch statement that combines their logic would work great for this. Something like:

switch {
case ...:
    req.Header.Set("Accept", ...)
case ...:
    req.Header.Set("Accept", ...)
}

That'll make the code more readable and easier to maintain.

github/search.go Outdated
CommitterID *int `json:"committer_id,omitempty"`
CommitterName *string `json:"committer_name,omitempty"`
CommitterEmail *string `json:"committer_email,omitempty"`
CommitterDate *string `json:"committer_date,omitempty"`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you sure AuthorDate and CommitterDate should be *string instead of *Timestamp?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, it should be *Timestamp only. Changed it.

github/search.go Outdated
@@ -54,6 +55,37 @@ func (s *SearchService) Repositories(query string, opt *SearchOptions) (*Reposit
return result, resp, err
}

// SingleCommitResult represents a commit object as returned in commit search endpoint response.
type SingleCommitResult struct {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you think of following the style set forward by CodeResult and name this CommitResult?

// CodeResult represents a single search result.
type CodeResult struct {

Source:

go-github/github/search.go

Lines 115 to 116 in c9c37fd

// CodeResult represents a single search result.
type CodeResult struct {
.

The prefix Single doesn't seem to be needed, is it? Unless it's needed, it's better to remove it to have a simpler struct name.

@sahildua2305
Copy link
Member Author

Thanks @shurcooL, I will make the changes as suggested.

-   Make code consistent with the current code.
-   Simplified logic for setting Accept headers.
-   Changed AuthorDate and CommitterDate type from *string
to *Timestamp.
@sahildua2305
Copy link
Member Author

@shurcooL I have made changes as you suggested.

@sahildua2305
Copy link
Member Author

@shurcooL can you please this again?

Copy link
Member

@dmitshur dmitshur left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One change request, everything else looks good. Thanks for addressing all previous feedback!

github/search.go Outdated
req.Header.Set("Accept", "application/vnd.github.v3.text-match+json")
case searchType == "commits":
// Accept header for search commits preview endpoint
req.Header.Set("Accept", mediaTypeCommitSearchPreview)
Copy link
Member

@dmitshur dmitshur Jan 27, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Two things here.

  1. Add a // TODO: remove custom Accept header when this API fully launches. comment.

  2. Now that these cases are in the same switch, it's a little easier to reason about them. I think we should give the searchType == "commits" higher priority than opt != nil && opt.TextMatch. It may not even be valid to set opt.TextMatch: true for a commit search, but if someone does, it would fail to return any results at all because the custom accept header wouldn't be set.

    So, let's be safe and put the searchType == "commits" case on top, so that the API preview header is always set when doing a commit search.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shurcooL made the changes. Please have a look. :)

-   Move commits case above the textMatch one.
-   Add TODO for removing custom header when API fully launches
Copy link
Member

@dmitshur dmitshur left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks @sahildua2305!

Mind looking it over @gmlewis?

@dmitshur dmitshur requested a review from gmlewis January 31, 2017 16:15
Copy link
Collaborator

@gmlewis gmlewis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, @sahildua2305!
Please address the slice-of-values vs slice-of-pointers.

@shurcooL - what do you think about the field naming questions?

github/search.go Outdated
type CommitsSearchResult struct {
Total *int `json:"total_count,omitempty"`
IncompleteResults *bool `json:"incomplete_results,omitempty"`
Commits []CommitResult `json:"items,omitempty"`
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please change this to:

Commits           []*CommitResult `json:"items,omitempty"`

Also, wouldn't we want Items here?

Copy link
Member

@dmitshur dmitshur Jan 31, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, the current version of not using Items as the name, and not having pointers is consistent with other structs.

However, we can probably deviate on the pointers. What do you think?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I definitely think the pointer version is better despite any inconsistencies, especially for new structs. See #180 for discussion.

As for Commits, that's fine with me.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SGTM. @sahildua2305, please go ahead with this []*CommitResult change.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@gmlewis @shurcooL done 👍

github/search.go Outdated
@@ -54,6 +55,37 @@ func (s *SearchService) Repositories(query string, opt *SearchOptions) (*Reposit
return result, resp, err
}

// CommitsSearchResult represents the result of a commits search.
type CommitsSearchResult struct {
Total *int `json:"total_count,omitempty"`
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't it reduce confusion if the Go field name matched the JSON field name?
In other words, use TotalCount here?

Copy link
Member

@dmitshur dmitshur Jan 31, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In a normal situation, I would fully agree.

However, please look at the other similar structs in this file @gmlewis. See RepositoriesSearchResult, CodeSearchResult, etc.

They consistently call total_count as Total.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, SGTM.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you think it's worth changing (outside this PR), we can make a separate issue/PR to discuss that. But I suspect the cost (breaking API) wouldn't be worth the small benefit (more consistency).

want := &CommitsSearchResult{
Total: Int(4),
IncompleteResults: Bool(false),
Commits: []CommitResult{{Hash: String("random_hash1")}, {Hash: String("random_hash2")}},
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[]*CommitResult...

Copy link
Collaborator

@gmlewis gmlewis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thank you, @sahildua2305!

@gmlewis
Copy link
Collaborator

gmlewis commented Jan 31, 2017

Merging.

@gmlewis gmlewis closed this in 3b59f32 Jan 31, 2017
@gmlewis
Copy link
Collaborator

gmlewis commented Jan 31, 2017

Integrated in 3b59f32

@sahildua2305
Copy link
Member Author

Thanks @gmlewis

@sahildua2305 sahildua2305 deleted the add-commit-search branch January 31, 2017 22:30
bubg-dev pushed a commit to bubg-dev/go-github that referenced this pull request Jun 16, 2017
Added support for this new preview endpoint which lets users
search for commits based on various conditions.

GitHub announcement -
https://developer.github.com/changes/2017-01-05-commit-search-api/
Docs - https://developer.github.com/v3/search/#search-commits

Fixes google#508.
Closes google#520.

Change-Id: I2210fafe3da530716075f9113851e09e3bc671f8
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants