update: use GitHub API to avoid unneeded fetches.

[MikeMcQuaid]

Check to see if HEAD is the same as what we have locally. If it is: don't bother to git fetch.

Note that this is a preview GitHub API so it may change in future.

CC @xu-cheng @UniqMartin

[xu-cheng]

It could improve the code style by early return here. i.e

if [[ "$UPSTREAM_REPOSITORY_URL" = "https://github.com/"* ]]
then
  ...
  [[ "$UPSTREAM_SHA_HTTP_CODE" = "304" ]] && return
fi

As result, we won't have the case where UPSTREAM_SHA_HTTP_CODE never being set, which looks weird.

[MikeMcQuaid]

🆒 but think it's exit as it's a subshell. Will try both,though.

[UniqMartin]

No objection to the general approach, but here's a random thought: Would it make sense to move everything that doesn't deal with the network (namely checking/processing the upstream repository URL) outside of the parentheses and thus out of the subshell, such that only the curl and git fetch (with some minimal logic around them) remain? I guess one upside could be that it is easier to debug, if there's ever something to debug in this part of the code.

[MikeMcQuaid]

Would it make sense to move everything that doesn't deal with the network (namely checking/processing the upstream repository URL) outside of the parentheses and thus out of the subshell, such that only the curl and git fetch (with some minimal logic around them) remain?

Good idea. None of that stuff seems like a performance bottle-neck. 👍 to using parallel processing only to speed things up 👍

[MikeMcQuaid]

No objection to the general approach, but here's a random thought: Would it make sense to move everything that doesn't deal with the network (namely checking/processing the upstream repository URL) outside of the parentheses and thus out of the subshell, such that only the curl and git fetch (with some minimal logic around them) remain?

Decided against this just due to Bash's global state + multithreading = 😭

Thanks for the review, pulling!

[UniqMartin]

Decided against this just due to Bash's global state + multithreading = 😭

As far as I understand this, this shouldn't be an issue because the parallelism is entirely process- and not thread-based. Thus once the variables have been set up, the subshell gets created and gets its own copy of the variables from the parent shell. Whatever the subshell does to those variables doesn't influence the parent shell and vice versa.

That said, the change is good as is and we can iterate on it later, maybe once another change needs to touch this code and pulling out those variables creates some kind of benefit.

Thanks for the review, pulling!

👏

I'm looking forward to the reports that claim brew update is broken because it finished too quickly. 😏