delta/git.git, branch pm/build-persistent-https-with-recent-go

contrib/persistent-https: use Git version for build label

2016-07-22T17:59:03+00:00

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 version
contained in the GIT-VERSION-FILE. This gives a better sense of the version
of the binary as it can be mapped to a particular revision or release of
Git itself. For example:

    $ make && ./git-remote-persistent-http -print_label
    2.9.1.275.g75676c8

Discussion of this patch is available on a related thread in the mailing
list surrounding this package called "contrib/persistent-https: update
ldflags syntax for Go 1.7+". The gmane.org link is:
http://article.gmane.org/gmane.comp.version-control.git/299653/

Signed-off-by: Parker Moore 
Signed-off-by: Junio C Hamano

contrib/persistent-https: update ldflags syntax for Go 1.7+

2016-07-22T17:54:11+00:00

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-https \
   -ldflags "-X main._BUILD_EMBED_LABEL 1468613136"
    # _/Users/parkr/github/git/contrib/persistent-https
    /usr/local/Cellar/go/1.7rc1/libexec/pkg/tool/darwin_amd64/link: -X
flag requires argument of the form importpath.name=value
    make: *** [git-remote-persistent-https] Error 2

This `name=value` syntax for the -X flag was introduced in Go v1.5
(released Aug 19, 2015):

 - release notes: https://golang.org/doc/go1.5#link
 - commit: https://github.com/golang/go/commit/12795c02f3d6fc54ece09a86e70aaa40a94d5131

In Go v1.7, support for the old syntax was removed:

 - release notes: https://tip.golang.org/doc/go1.7#compiler
 - commit: https://github.com/golang/go/commit/51b624e6a29b135ce0fadb22b678acf4998ff16f

Add '=' between the symbol and its value for recent versions of Go,
while leaving it out for older ones.

Signed-off-by: Parker Moore 
Signed-off-by: Junio C Hamano

Git 2.6.6

2016-03-17T18:26:41+00:00

Signed-off-by: Junio C Hamano

Merge branch 'maint-2.5' into maint-2.6

2016-03-17T18:26:18+00:00

* maint-2.5:
  Git 2.5.5
  Git 2.4.11
  list-objects: pass full pathname to callbacks
  list-objects: drop name_path entirely
  list-objects: convert name_path to a strbuf
  show_object_with_name: simplify by using path_name()
  http-push: stop using name_path
  tree-diff: catch integer overflow in combine_diff_path allocation
  add helpers for detecting size_t overflow

Git 2.5.5

2016-03-17T18:24:59+00:00

Signed-off-by: Junio C Hamano

Merge branch 'maint-2.4' into maint-2.5

2016-03-17T18:24:14+00:00

* maint-2.4:
  Git 2.4.11
  list-objects: pass full pathname to callbacks
  list-objects: drop name_path entirely
  list-objects: convert name_path to a strbuf
  show_object_with_name: simplify by using path_name()
  http-push: stop using name_path
  tree-diff: catch integer overflow in combine_diff_path allocation
  add helpers for detecting size_t overflow

Git 2.4.11

2016-03-17T18:23:05+00:00

Signed-off-by: Junio C Hamano

Merge branch 'jk/path-name-safety-2.4' into maint-2.4

2016-03-17T18:22:24+00:00

Bugfix patches were backported from the 'master' front to plug heap
corruption holes, to catch integer overflow in the computation of
pathname lengths, and to get rid of the name_path API.  Both of
these would have resulted in writing over an under-allocated buffer
when formulating pathnames while tree traversal.

* jk/path-name-safety-2.4:
  list-objects: pass full pathname to callbacks
  list-objects: drop name_path entirely
  list-objects: convert name_path to a strbuf
  show_object_with_name: simplify by using path_name()
  http-push: stop using name_path
  tree-diff: catch integer overflow in combine_diff_path allocation
  add helpers for detecting size_t overflow

list-objects: pass full pathname to callbacks

2016-03-16T17:41:04+00:00

When we find a blob at "a/b/c", we currently pass this to
our show_object_fn callbacks as two components: "a/b/" and
"c". Callbacks which want the full value then call
path_name(), which concatenates the two. But this is an
inefficient interface; the path is a strbuf, and we could
simply append "c" to it temporarily, then roll back the
length, without creating a new copy.

So we could improve this by teaching the callsites of
path_name() this trick (and there are only 3). But we can
also notice that no callback actually cares about the
broken-down representation, and simply pass each callback
the full path "a/b/c" as a string. The callback code becomes
even simpler, then, as we do not have to worry about freeing
an allocated buffer, nor rolling back our modification to
the strbuf.

This is theoretically less efficient, as some callbacks
would not bother to format the final path component. But in
practice this is not measurable. Since we use the same
strbuf over and over, our work to grow it is amortized, and
we really only pay to memcpy a few bytes.

Signed-off-by: Jeff King 
Signed-off-by: Junio C Hamano

list-objects: drop name_path entirely

2016-03-16T17:41:03+00:00

In the previous commit, we left name_path as a thin wrapper
around a strbuf. This patch drops it entirely. As a result,
every show_object_fn callback needs to be adjusted. However,
none of their code needs to be changed at all, because the
only use was to pass it to path_name(), which now handles
the bare strbuf.

Signed-off-by: Jeff King 
Signed-off-by: Junio C Hamano