> We tend to avoid catting a single file only to pipe the result into a
> different command
You got it. Here's a new patch:
>From 432c0054a28a6c91b9fc1d9b53714061cb3d903c Mon Sep 17 00:00:00 2001
From: Parker Moore <parkrmo...@gmail.com>
Date: Wed, 20 Jul 2016 18:33:28 -0600
From: Parker Moore <parkrmo...@gmail.com>
The previous method simply used the UNIX timestamp of when the binary was
built as its build label.
$ make && ./git-remote-persistent-http -print_label
1469061546
This patch aims to align the label for this binary with the Git ver
From: Parker Moore <parkrmo...@gmail.com>
This fixes contrib/persistent-https builds for Go v1.7+ and is
compatible with Go v1.0+.
Running `make all` in `contrib/persistent-https` results in a failure
on Go 1.7 and above.
Specifically, the error is:
go build -o git-remote-persistent
> the logical place to pull that information from would be
> ../../GIT-VERSION-FILE,
I agree. It would make more sense to build this to a specific version
or git revision rather
than a time. Perhaps that would be a different patch?
> So unless the "dynamic lookup in the Makefile" turns out to
> The label does not even identify the version of the source in any way, so I
> am not sure how people are depending on that feature anyway ;-)
Would it be a better solution simply to remove this build flag?
Alternatively, if Git wished to support Go v1.5 and below, I would be
more than happy to
From: Parker Moore <parkrmo...@gmail.com>
This fixes contrib/persistent-https builds for Go v1.7+ and is
compatible with Go v1.5+.
Running `make all` in `contrib/persistent-https` results in a failure
on Go 1.7 and above.
Specifically, the error is:
go build -o git-remote-persistent
6 matches
Mail list logo
