From https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204772
Version changed to make it work with fmake.
Differential D4514
Add GH_TUPLE mat on Dec 11 2015, 11:11 AM. Authored by Tags None Referenced Files
Subscribers
Details
From https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204772 Version changed to make it work with fmake.
Diff Detail
Event TimelineComment Actions 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.
Comment Actions @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. Comment Actions @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. Comment Actions 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 |