mirrors/git
0
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-29 04:54:56 +08:00
Code Issues Packages Projects Releases Wiki Activity
fd9e226776
git/Documentation/git-bugreport.txt

55 lines
1.6 KiB
Plaintext
Raw Normal View History

bugreport: add tool to generate debugging info Teach Git how to prompt the user for a good bug report: reproduction steps, expected behavior, and actual behavior. Later, Git can learn how to collect some diagnostic information from the repository. If users can send us a well-written bug report which contains diagnostic information we would otherwise need to ask the user for, we can reduce the number of question-and-answer round trips between the reporter and the Git contributor. Users may also wish to send a report like this to their local "Git expert" if they have put their repository into a state they are confused by. Signed-off-by: Emily Shaffer <emilyshaffer@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-17 05:18:04 +08:00
git-bugreport(1)
================
NAME
----
git-bugreport - Collect information for user to file a bug report
SYNOPSIS
--------
[verse]
'git bugreport' [(-o | --output-directory) <path>] [(-s | --suffix) <format>]
DESCRIPTION
-----------
Captures information about the user's machine, Git client, and repository state,
as well as a form requesting information about the behavior the user observed,
into a single text file which the user can then share, for example to the Git
mailing list, in order to report an observed bug.
The following information is requested from the user:
- Reproduction steps
- Expected behavior
- Actual behavior
bugreport: gather git version and build info Knowing which version of Git a user has and how it was built allows us to more precisely pin down the circumstances when a certain issue occurs, so teach bugreport how to tell us the same output as 'git version --build-options'. It's not ideal to directly call 'git version --build-options' because that output goes to stdout. Instead, wrap the version string in a helper within help.[ch] library, and call that helper from within the bugreport library. Signed-off-by: Emily Shaffer <emilyshaffer@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-17 05:18:05 +08:00
The following information is captured automatically:
- 'git version --build-options'
bugreport: add uname info The contents of uname() can give us some insight into what sort of system the user is running on, and help us replicate their setup if need be. The domainname field is not guaranteed to be available, so don't collect it. Signed-off-by: Emily Shaffer <emilyshaffer@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-17 05:18:06 +08:00
- uname sysname, release, version, and machine strings
bugreport: add compiler info To help pinpoint the source of a regression, it is useful to know some info about the compiler which the user's Git client was built with. By adding a generic get_compiler_info() in 'compat/' we can choose which relevant information to share per compiler; to get started, let's demonstrate the version of glibc if the user built with 'gcc'. Signed-off-by: Emily Shaffer <emilyshaffer@google.com> Helped-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Helped-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-17 05:18:07 +08:00
- Compiler-specific info string
bugreport: collect list of populated hooks Occasionally a failure a user is seeing may be related to a specific hook which is being run, perhaps without the user realizing. While the contents of hooks can be sensitive - containing user data or process information specific to the user's organization - simply knowing that a hook is being run at a certain stage can help us to understand whether something is going wrong. Without a definitive list of hook names within the code, we compile our own list from the documentation. This is likely prone to bitrot, but designing a single source of truth for acceptable hooks is too much overhead for this small change to the bugreport tool. Signed-off-by: Emily Shaffer <emilyshaffer@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-08 08:53:57 +08:00
- A list of enabled hooks
bugreport: include user interactive shell It's possible a user may complain about the way that Git interacts with their interactive shell, e.g. autocompletion or shell prompt. In that case, it's useful for us to know which shell they're using interactively. Signed-off-by: Emily Shaffer <emilyshaffer@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-13 07:42:13 +08:00
- $SHELL
bugreport: gather git version and build info Knowing which version of Git a user has and how it was built allows us to more precisely pin down the circumstances when a certain issue occurs, so teach bugreport how to tell us the same output as 'git version --build-options'. It's not ideal to directly call 'git version --build-options' because that output goes to stdout. Instead, wrap the version string in a helper within help.[ch] library, and call that helper from within the bugreport library. Signed-off-by: Emily Shaffer <emilyshaffer@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-17 05:18:05 +08:00
bugreport: add tool to generate debugging info Teach Git how to prompt the user for a good bug report: reproduction steps, expected behavior, and actual behavior. Later, Git can learn how to collect some diagnostic information from the repository. If users can send us a well-written bug report which contains diagnostic information we would otherwise need to ask the user for, we can reduce the number of question-and-answer round trips between the reporter and the Git contributor. Users may also wish to send a report like this to their local "Git expert" if they have put their repository into a state they are confused by. Signed-off-by: Emily Shaffer <emilyshaffer@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-17 05:18:04 +08:00
This tool is invoked via the typical Git setup process, which means that in some
cases, it might not be able to launch - for example, if a relevant config file
is unreadable. In this kind of scenario, it may be helpful to manually gather
the kind of information listed above when manually asking for help.
OPTIONS
-------
-o <path>::
--output-directory <path>::
Place the resulting bug report file in `<path>` instead of the root of
the Git repository.
-s <format>::
--suffix <format>::
Specify an alternate suffix for the bugreport name, to create a file
named 'git-bugreport-<formatted suffix>'. This should take the form of a
git-bugreport.txt: adjust reference to strftime(3) The strftime(3) man page is outside of the Git suite. Refererence it as we do other external man pages and avoid creating a broken link when generating the HTML documentation. Signed-off-by: Todd Zullinger <tmz@pobox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-19 03:37:36 +08:00
strftime(3) format string; the current local time will be used.
bugreport: add tool to generate debugging info Teach Git how to prompt the user for a good bug report: reproduction steps, expected behavior, and actual behavior. Later, Git can learn how to collect some diagnostic information from the repository. If users can send us a well-written bug report which contains diagnostic information we would otherwise need to ask the user for, we can reduce the number of question-and-answer round trips between the reporter and the Git contributor. Users may also wish to send a report like this to their local "Git expert" if they have put their repository into a state they are confused by. Signed-off-by: Emily Shaffer <emilyshaffer@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-17 05:18:04 +08:00
GIT
---
Part of the linkgit:git[1] suite
Reference in New Issue Copy Permalink