From: Johannes Schindelin <hidden> Date: 2017-12-08 17:02:20
In Git for Windows, we ask users to paste the output of said command
into their bug reports, with the idea that this frequently helps
identify where the problems are coming from.
There are some obvious missing bits of information in said output,
though, and this patch series tries to fill the gaps at least a little.
Adric Norris (1):
git version --build-options: report the build platform, too
Johannes Schindelin (1):
version --build-options: report commit, too, if possible
Makefile | 4 +++-
help.c | 4 ++++
help.h | 13 +++++++++++++
version.c | 1 +
version.h | 1 +
5 files changed, 22 insertions(+), 1 deletion(-)
base-commit: 95ec6b1b3393eb6e26da40c565520a8db9796e9f
Published-As: https://github.com/dscho/git/releases/tag/built-from-commit-v1
Fetch-It-Via: git fetch https://github.com/dscho/git built-from-commit-v1
--
2.15.1.windows.2
From: Johannes Schindelin <hidden> Date: 2017-12-08 17:02:38
From: Adric Norris <redacted>
When asking for bug reports to include the output of `git version
--build-options`, the idea is that we get a better idea of the
environment where said bug occurs. In this context, it is useful to
distinguish between 32 and 64-bit builds.
We start by distinguishing between x86 and x86_64 (hoping that
interested parties will extend this to other architectures in the
future). In addition, all 32-bit variants (i686, i586, etc.) are
collapsed into `x86'. An example of the output is:
$ git version --build-options
git version 2.9.3.windows.2.826.g06c0f2f
sizeof-long: 4
machine: x86_64
The label of `machine' was chosen so the new information will approximate
the output of `uname -m'.
Signed-off-by: Adric Norris <redacted>
Signed-off-by: Johannes Schindelin <redacted>
---
help.c | 2 ++
help.h | 13 +++++++++++++
2 files changed, 15 insertions(+)
From: Johannes Schindelin <hidden> Date: 2017-12-08 17:02:45
In particular when local tags are used (or tags that are pushed to some
fork) to build Git, it is very hard to figure out from which particular
revision a particular Git executable was built.
Let's just report that in our build options.
We need to be careful, though, to report when the current commit cannot be
determined, e.g. when building from a tarball without any associated Git
repository.
Signed-off-by: Johannes Schindelin <redacted>
---
Makefile | 4 +++-
help.c | 2 ++
version.c | 1 +
version.h | 1 +
4 files changed, 7 insertions(+), 1 deletion(-)
@@ -413,6 +413,8 @@ int cmd_version(int argc, const char **argv, const char *prefix)printf("git version %s\n",git_version_string);if(build_options){+printf("built from commit: %s\n",+git_built_from_commit_string);printf("sizeof-long: %d\n",(int)sizeof(long));printf("machine: %s\n",build_platform);/* NEEDSWORK: also save and output GIT-BUILD_OPTIONS? */
From: Jonathan Nieder <hidden> Date: 2017-12-08 17:23:32
Hi,
Johannes Schindelin wrote:
From: Adric Norris <redacted>
When asking for bug reports to include the output of `git version
--build-options`, the idea is that we get a better idea of the
environment where said bug occurs. In this context, it is useful to
distinguish between 32 and 64-bit builds.
Neat!
The cover letter gives a clearer idea of the motivation:
In Git for Windows, we ask users to paste the output of said command
into their bug reports, with the idea that this frequently helps
identify where the problems are coming from.
There are some obvious missing bits of information in said output,
though, and this patch series tries to fill the gaps at least a little.
Could some of that text go here, too?
[...]
Can this use GIT_BUILD_PLATFORM directly instead of going via the indirection
of a mutable static string? That is, something like
printf("machine: %s\n", GIT_BUILD_PLATFORM);
/* NEEDSWORK: also save and output GIT-BUILD_OPTIONS? */
What do you think of this idea? uname_M isn't one of the variables
in that file, though, so that's orthogonal to this patch.
[...]
quoted hunk
--- a/help.h+++ b/help.h
@@ -33,3 +33,16 @@ extern void list_commands(unsigned int colopts, struct cmdnames *main_cmds, stru*/externvoidhelp_unknown_ref(constchar*ref,constchar*cmd,constchar*error);#endif /* HELP_H */++/*+*identifybuildplatform+*/+#ifndef GIT_BUILD_PLATFORM+#if defined __x86__ || defined __i386__ || defined __i586__ || defined __i686__+#define GIT_BUILD_PLATFORM "x86"+#elif defined __x86_64__+#define GIT_BUILD_PLATFORM "x86_64"+#else+#define GIT_BUILD_PLATFORM "unknown"+#endif+#endif
This code needs to be inside the HELP_H header guard.
Thanks and hope that helps,
Jonathan
From: Jonathan Nieder <hidden> Date: 2017-12-08 17:27:43
Hi,
Johannes Schindelin wrote:
In particular when local tags are used (or tags that are pushed to some
fork) to build Git, it is very hard to figure out from which particular
revision a particular Git executable was built.
Hm, can you say more about how this comes up in practice? I wonder if
we should always augment the version string with the commit hash.
E.g. I am running
git version 2.15.1.424.g9478a66081
now, which already includes the commit hash because it disambiguates
the .424 thing, but depending on the motivation, maybe we would also
want
git version 2.15.1.0.g9b185bef0c15
for people running v2.15.1 (or at least when such a tag is not a well
known, published tag).
We need to be careful, though, to report when the current commit cannot be
determined, e.g. when building from a tarball without any associated Git
repository.
This means that on Debian, it would always print
built from commit: (unknown)
Maybe I shouldn't care, but I wonder if there's a way to improve on
that. E.g. should there be a makefile knob to allow Debian to specify
what to put there?
Thanks,
Jonathan
From: Johannes Schindelin <hidden> Date: 2017-12-14 23:26:10
Hi Jonathan,
On Fri, 8 Dec 2017, Jonathan Nieder wrote:
Johannes Schindelin wrote:
quoted
In particular when local tags are used (or tags that are pushed to some
fork) to build Git, it is very hard to figure out from which particular
revision a particular Git executable was built.
Hm, can you say more about how this comes up in practice?
I recently saw a version string on this here list (in a generated patch)
that looked something like "git v2.14.0.chrome".
I sometimes build custom Git for Windows snapshots from commits that I
keep in my own fork. I would expect other people to do the same.
With this patch, at least I can verify very easily whether I have access
to the corresponding commit or not.
I wonder if we should always augment the version string with the commit
hash.
That would probably be more confusing than helpful to the end-users.
E.g. I am running
git version 2.15.1.424.g9478a66081
which is currently good enough, but in the future may clash with another
object, maybe even a commit. Unabbreviated commit names are what I am
after.
quoted
We need to be careful, though, to report when the current commit cannot be
determined, e.g. when building from a tarball without any associated Git
repository.
This means that on Debian, it would always print
built from commit: (unknown)
Maybe I shouldn't care, but I wonder if there's a way to improve on
that. E.g. should there be a makefile knob to allow Debian to specify
what to put there?
I changed the text to "no commit associated with this build". Does that
suffice? If not, what "UI" would you suggest (most likely a new Makefile
variable? What name would you prefer?).
Ciao,
Dscho
From: Johannes Schindelin <hidden> Date: 2017-12-14 23:34:38
In Git for Windows, we ask users to paste the output of said command
into their bug reports, with the idea that this frequently helps
identify where the problems are coming from.
There are some obvious missing bits of information in said output,
though, and this patch series tries to fill the gaps at least a little.
Changes since v1:
- replaced 1/2 by Eric's proposed alternative patch
- when no commit can be determined, it now says
no commit associated with this build
instead of
built from commit: (unknown)
- the code is now careful not to look further than Git's top-level
directory for a Git repository from which to determine the current
commit. As Junio pointed out, some developer may extract Git's source
code from a tarball into a worktree of a completely different project.
Eric Sunshine (1):
version --build-options: also report host CPU
Johannes Schindelin (1):
version --build-options: report commit, too, if possible
Makefile | 13 ++++++++++++-
help.c | 6 ++++++
version.c | 1 +
version.h | 1 +
4 files changed, 20 insertions(+), 1 deletion(-)
base-commit: 95ec6b1b3393eb6e26da40c565520a8db9796e9f
Published-As: https://github.com/dscho/git/releases/tag/built-from-commit-v2
Fetch-It-Via: git fetch https://github.com/dscho/git built-from-commit-v2
Interdiff vs v1:
diff --git a/Makefile b/Makefile
index 92a0ae3d8e3..2ce70d205d9 100644
--- a/Makefile
+++ b/Makefile
@@ -425,6 +425,9 @@ all::
#
# to say "export LESS=FRX (and LV=-c) if the environment variable
# LESS (and LV) is not set, respectively".
+#
+# When cross-compiling, define HOST_CPU as the canonical name of the CPU on
+# which the built Git will run (for instance "x86_64").
GIT-VERSION-FILE: FORCE
@$(SHELL_PATH) ./GIT-VERSION-GEN
@@ -1095,6 +1098,12 @@ else
BROKEN_PATH_FIX = '/^\# @@BROKEN_PATH_FIX@@$$/d'
endif
+ifeq (,$(HOST_CPU))
+ BASIC_CFLAGS += -DGIT_HOST_CPU="\"$(firstword $(subst -, ,$(uname_M)))\""
+else
+ BASIC_CFLAGS += -DGIT_HOST_CPU="\"$(HOST_CPU)\""
+endif
+
ifneq (,$(INLINE))
BASIC_CFLAGS += -Dinline=$(INLINE)
endif
@@ -1894,8 +1903,8 @@ version.sp version.s version.o: GIT-VERSION-FILE GIT-USER-AGENT
version.sp version.s version.o: EXTRA_CPPFLAGS = \
'-DGIT_VERSION="$(GIT_VERSION)"' \
'-DGIT_USER_AGENT=$(GIT_USER_AGENT_CQ_SQ)' \
- '-DGIT_BUILT_FROM_COMMIT="$(shell git rev-parse -q --verify HEAD || \
- echo "(unknown)")"'
+ '-DGIT_BUILT_FROM_COMMIT="$(shell GIT_CEILING_DIRECTORIES=\"$(CURDIR)/..\" \
+ git rev-parse -q --verify HEAD || :)"'
$(BUILT_INS): git$X
$(QUIET_BUILT_IN)$(RM) $@ && \
diff --git a/help.c b/help.c
index 6ebea665780..60071a9beaa 100644
--- a/help.c
+++ b/help.c
@@ -390,7 +390,6 @@ const char *help_unknown_cmd(const char *cmd)
int cmd_version(int argc, const char **argv, const char *prefix)
{
- static char build_platform[] = GIT_BUILD_PLATFORM;
int build_options = 0;
const char * const usage[] = {
N_("git version [<options>]"),
@@ -413,10 +412,13 @@ int cmd_version(int argc, const char **argv, const char *prefix)
printf("git version %s\n", git_version_string);
if (build_options) {
- printf("built from commit: %s\n",
- git_built_from_commit_string);
+ printf("cpu: %s\n", GIT_HOST_CPU);
+ if (git_built_from_commit_string[0])
+ printf("built from commit: %s\n",
+ git_built_from_commit_string);
+ else
+ printf("no commit associated with this build\n");
printf("sizeof-long: %d\n", (int)sizeof(long));
- printf("machine: %s\n", build_platform);
/* NEEDSWORK: also save and output GIT-BUILD_OPTIONS? */
}
return 0;
diff --git a/help.h b/help.h
index 42dd9852194..b21d7c94e8c 100644
--- a/help.h
+++ b/help.h
@@ -33,16 +33,3 @@ extern void list_commands(unsigned int colopts, struct cmdnames *main_cmds, stru
*/
extern void help_unknown_ref(const char *ref, const char *cmd, const char *error);
#endif /* HELP_H */
-
-/*
- * identify build platform
- */
-#ifndef GIT_BUILD_PLATFORM
- #if defined __x86__ || defined __i386__ || defined __i586__ || defined __i686__
- #define GIT_BUILD_PLATFORM "x86"
- #elif defined __x86_64__
- #define GIT_BUILD_PLATFORM "x86_64"
- #else
- #define GIT_BUILD_PLATFORM "unknown"
- #endif
-#endif
--
2.15.1.windows.2
From: Johannes Schindelin <hidden> Date: 2017-12-14 23:34:46
From: Eric Sunshine <redacted>
It can be helpful for bug reports to include information about the
environment in which the bug occurs. "git version --build-options" can
help to supplement this information. In addition to the size of 'long'
already reported by --build-options, also report the host's CPU type.
Example output:
$ git version --build-options
git version 2.9.3.windows.2.826.g06c0f2f
cpu: x86_64
sizeof-long: 4
New Makefile variable HOST_CPU supports cross-compiling.
Suggested-by: Adric Norris <redacted>
Signed-off-by: Eric Sunshine <redacted>
Signed-off-by: Johannes Schindelin <redacted>
---
Makefile | 9 +++++++++
help.c | 1 +
2 files changed, 10 insertions(+)
@@ -425,6 +425,9 @@ all::## to say "export LESS=FRX (and LV=-c) if the environment variable# LESS (and LV) is not set, respectively".+#+# When cross-compiling, define HOST_CPU as the canonical name of the CPU on+# which the built Git will run (for instance "x86_64").GIT-VERSION-FILE:FORCE@$(SHELL_PATH)./GIT-VERSION-GEN
@@ -412,6 +412,7 @@ int cmd_version(int argc, const char **argv, const char *prefix)printf("git version %s\n",git_version_string);if(build_options){+printf("cpu: %s\n",GIT_HOST_CPU);printf("sizeof-long: %d\n",(int)sizeof(long));/* NEEDSWORK: also save and output GIT-BUILD_OPTIONS? */}
From: Johannes Schindelin <hidden> Date: 2017-12-14 23:34:48
In particular when local tags are used (or tags that are pushed to some
fork) to build Git, it is very hard to figure out from which particular
revision a particular Git executable was built. It gets worse when those
tags are deleted, or even updated.
Let's just report an exact, unabbreviated commit name in our build
options.
We need to be careful, though, to report when the current commit cannot
be determined, e.g. when building from a tarball without any associated
Git repository. This could be the case also when extracting Git's source
code into an unrelated Git worktree.
Signed-off-by: Johannes Schindelin <redacted>
---
Makefile | 4 +++-
help.c | 5 +++++
version.c | 1 +
version.h | 1 +
4 files changed, 10 insertions(+), 1 deletion(-)
@@ -413,6 +413,11 @@ int cmd_version(int argc, const char **argv, const char *prefix)if(build_options){printf("cpu: %s\n",GIT_HOST_CPU);+if(git_built_from_commit_string[0])+printf("built from commit: %s\n",+git_built_from_commit_string);+else+printf("no commit associated with this build\n");printf("sizeof-long: %d\n",(int)sizeof(long));/* NEEDSWORK: also save and output GIT-BUILD_OPTIONS? */}