Go 1.10 release notes:
> The go build -asmflags, -gcflags, -gccgoflags, and -ldflags options
> now apply by default only to the packages listed directly on the
> command line. For example, go build -gcflags=-m mypkg passes the
> compiler the -m flag when building mypkg but not its dependencies. The
> new, more general form -asmflags=pattern=flags (and similarly for the
> others) applies the flags only to the packages matching the pattern.
> For example: go install -ldflags=cmd/gofmt=-X=main.version=1.2.3
> cmd/... installs all the commands matching cmd/... but only applies
> the -X option to the linker flags for cmd/gofmt. For more details, see
> go help build.
golang does not natively respect LDFLAGS, but you can pass them on the
command line using -ldflags=-extldflags=...
This is important for distributions, in order to provide common
functionality such as hardening flags.
Also strip the prefixed root source directory from the embedded source
file paths. This is not important information for the debugger, which
should only care about paths relative to $GOPATH, and results in less
build environment metadata leaking into the final binary. (This also
aids in reproducible builds when using different build directories, see
e.g. https://github.com/golang/go/issues/16860)
If the environment variable SOURCE_DATE_EPOCH is set in the build
environment, prefer it over the current date when determining the
correct timestamp to use as the date the manpages were built.
See https://reproducible-builds.org/specs/source-date-epoch/
5 years ago, in anticipation of an API change, I have made the call to
deprecate issue-to-PR conversion in hub. 4f70dd126f
Issue-to-PR conversion was wonky at those times, poorly understood, and
was generating a lot of support requests to hub's issue tracker that I
didn't want to deal with. In most cases, people tried to convert issues
that they have no rights over and they would get a cryptic validation
error in the API response.
Since then, there was a consistent plea from the hub community to keep
this feature as some teams seem to rely on this for their workflows. I
have consulted with other GitHub employees about the stableness of this
feature, and anecdotal evidence suggests that lately there haven't been
as many problems around this as there have been in the past. Also, the
GitHub API v3 will not be getting breaking changes, so it sounds like
this feature is here to stay.
Fixes#1927
Ref. #532, #410, #1806, #1770, #1628
When running `hub pull-request` with this git remote setup:
* origin: `github.com/myuser/myfork`
* github: `github.com/owner/repo`
* upstream: `example.com/other-repo`
this error would be shown:
Aborted: the origin remote doesn't point to a GitHub repository.
The error is both unfortunate (the existence of "upstream" shouldn't
have aborted the whole operation) and misleading (it wasn't the "origin"
remote that was the problem).
This changes `MainProject()` so it skips over non-GitHub remotes until
it finds one that points to a GitHub project.
This changes the `MasterBranch()` implementation to consider upstream
remotes that might be named differently than "origin". The new
`DefaultBranch(remote)` function is now the preferred alternative.
Mislav Marohnić
Mislav Marohnić
Eli Schwartz
Andrew Janke