Can you describe how the targets fit into maintainer's workflow? It seems they try to facilitate update, only to leave error-prone copy-pasting to a human. In-place update of revisions/tags would be more reliable provided maintainer reviews svn diff output and reverts unnecessary hunks. For example, git add and git reset has -p option to edit what would end up in a commit, otherwise one would have to use an editor with diff-mode.

Mk/bsd.sites.mk

540

Why not use GitHub API ? For example,

$ git ls-remote https://github.com/rust-lang/cargo HEAD |
  sed -E 's/^(.{7}).*/\1/'
a4e2a0a

$ HTTP_USER_AGENT=curl fetch -qo- \
  https://api.github.com/repos/rust-lang/cargo/commits |
  sed -En '/sha/ { s/.*"(.{7}).*/\1/p; q; }'
a4e2a0a

With tags it'd be slightly longer.

$ git ls-remote https://github.com/rust-lang/cargo |
  awk -F/ '/tags/ && !/{}/ { print $3 }' | sort -nr | head -1
0.7.0

$ HTTP_USER_AGENT=curl fetch -qo- \
  https://api.github.com/repos/rust-lang/cargo/tags |
  awk -F: '/name/ { gsub("[\", ]",""); print $2 }' | sort -nr | head -1
0.7.0

551

Why not combine the targets?

gh-get-latest-revisions gh-get-changed-revisions:
	...
	case ${.TARGET} in \
		*changed*) \
		[ $$3 != "$$rev" ] && \
	...

@jbeich These targets were originally meant for information only, to avoid going into each individual project and compare last revisions.

Here we can only work with git's 'ls-remote' command which doesn't fetch much information. I don't believe it can even fetch dates/logs of tags. Git lacks API that allows more in-depth data retrieval from the remote repository. Even for 'git log https://...' it for some reason looks for the local repository.

I am going to rename them into gh-show-latest, gh-show-changed. And will add an interactive gh-import-latest that will patch them one by one.

@jbeich The problem with parsing json with awk is that this is generally not a proper way to parse json. The right way is to use textproc/jq utility, but ports framework doesn't have access to jq. When you parse with awk, you don't rely only on GitHub API, you also rely on the particular way how they format their json output, which might change any time. Please keep in mind that they may also expand their json output any time, and this won't be considered the violation of API as long as all parts of the older structure are still present. And awk expressions will just fail.

I also generally think of this as access to "git" repository, not necessarily to "github". It is probably a bad idea to be too GitHub-centric. I was actually going to propose to generalize all GH_ tags to GIT_ tags, because I believe people will be using their private "githubs": see the Gogs project https://gogs.io/. The upcoming port for Gogs is also dependent on GH_TUPLE patch.

So I would be leaning towards keeping it simple andn not venture into using the GitHub API extensively.

I think phabricator workflow is broken, doesn't allow me to add a new patch. It first says "Update patch for D4514", but when I upload the patch it only offers me to create or update the new diff number.

So I created the new one: https://reviews.freebsd.org/D4603

Closed by commit rP409898: Introduce GH_TUPLE. (authored by mat). · Explain WhyMar 1 2016, 8:23 PM

This revision was automatically updated to reflect the committed changes.