1. 22 Feb, 2019 2 commits
    • Jeff Hostetler's avatar
      trace2: collect Windows-specific process information · 353d3d77
      Jeff Hostetler authored
      Add platform-specific interface to log information about the current
      On Windows, this interface is used to indicate whether the git process
      is running under a debugger and list names of the process ancestors.
      Information for other platforms is left for a future effort.
      Signed-off-by: 's avatarJeff Hostetler <jeffhost@microsoft.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
    • Jeff Hostetler's avatar
      trace2: create new combined trace facility · ee4512ed
      Jeff Hostetler authored
      Create a new unified tracing facility for git.  The eventual intent is to
      replace the current trace_printf* and trace_performance* routines with a
      unified set of git_trace2* routines.
      In addition to the usual printf-style API, trace2 provides higer-level
      event verbs with fixed-fields allowing structured data to be written.
      This makes post-processing and analysis easier for external tools.
      Trace2 defines 3 output targets.  These are set using the environment
      variables "GIT_TR2", "GIT_TR2_PERF", and "GIT_TR2_EVENT".  These may be
      set to "1" or to an absolute pathname (just like the current GIT_TRACE).
      * GIT_TR2 is intended to be a replacement for GIT_TRACE and logs command
        summary data.
      * GIT_TR2_PERF is intended as a replacement for GIT_TRACE_PERFORMANCE.
        It extends the output with columns for the command process, thread,
        repo, absolute and relative elapsed times.  It reports events for
        child process start/stop, thread start/stop, and per-thread function
      * GIT_TR2_EVENT is a new structured format. It writes event data as a
        series of JSON records.
      Calls to trace2 functions log to any of the 3 output targets enabled
      without the need to call different trace_printf* or trace_performance*
      Signed-off-by: 's avatarJeff Hostetler <jeffhost@microsoft.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  2. 11 Apr, 2018 2 commits
    • Stefan Beller's avatar
      exec_cmd: rename to use dash in file name · d807c4a0
      Stefan Beller authored
      This is more consistent with the project style. The majority of Git's
      source files use dashes in preference to underscores in their file names.
      Signed-off-by: Stefan Beller's avatarStefan Beller <sbeller@google.com>
    • Dan Jacques's avatar
      exec_cmd: RUNTIME_PREFIX on some POSIX systems · 226c0ddd
      Dan Jacques authored
      Enable Git to resolve its own binary location using a variety of
      OS-specific and generic methods, including:
      - procfs via "/proc/self/exe" (Linux)
      - _NSGetExecutablePath (Darwin)
      - KERN_PROC_PATHNAME sysctl on BSDs.
      - argv0, if absolute (all, including Windows).
      This is used to enable RUNTIME_PREFIX support for non-Windows systems,
      notably Linux and Darwin. When configured with RUNTIME_PREFIX, Git will
      do a best-effort resolution of its executable path and automatically use
      this as its "exec_path" for relative helper and data lookups, unless
      explicitly overridden.
      Small incidental formatting cleanup of "exec_cmd.c".
      Signed-off-by: 's avatarDan Jacques <dnj@google.com>
      Thanks-to: Robbie Iannucci <iannucci@google.com>
      Thanks-to: Junio C Hamano <gitster@pobox.com>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  3. 05 Mar, 2018 1 commit
  4. 01 Feb, 2017 1 commit
  5. 29 Nov, 2016 1 commit
    • Jeff King's avatar
      common-main: stop munging argv[0] path · 6854a8f5
      Jeff King authored
      Since 650c4492 (common-main: call git_extract_argv0_path(),
      2016-07-01), the argv[0] that is seen in cmd_main() of
      individual programs is always the basename of the
      executable, as common-main strips off the full path. This
      can produce confusing results for git-daemon, which wants to
      re-exec itself.
      For instance, if the program was originally run as
      "/usr/lib/git/git-daemon", it will try just re-execing
      "git-daemon", which will find the first instance in $PATH.
      If git's exec-path has not been prepended to $PATH, we may
      find the git-daemon from a different version (or no
      git-daemon at all).
      Normally this isn't a problem. Git commands are run as "git
      daemon", the git wrapper puts the exec-path at the front of
      $PATH, and argv[0] is already "daemon" anyway. But running
      git-daemon via its full exec-path, while not really a
      recommended method, did work prior to 650c4492. Let's make
      it work again.
      The real goal of 650c4492 was not to munge argv[0], but to
      reliably set the argv0_path global. The only reason it
      munges at all is that one caller, the git.c wrapper,
      piggy-backed on that computation to find the command
      basename.  Instead, let's leave argv[0] untouched in
      common-main, and have git.c do its own basename computation.
      While we're at it, let's drop the return value from
      git_extract_argv0_path(). It was only ever used in this one
      callsite, and its dual purposes is what led to this
      confusion in the first place.
      Note that by changing the interface, the compiler can
      confirm for us that there are no other callers storing the
      return value. But the compiler can't tell us whether any of
      the cmd_main() functions (besides git.c) were relying on the
      basename munging. However, we can observe that prior to
      650c4492, no other cmd_main() functions did that munging,
      and no new cmd_main() functions have been introduced since
      then. So we can't be regressing any of those cases.
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
  6. 06 Jul, 2016 1 commit
  7. 01 Jul, 2016 5 commits
    • Jeff King's avatar
      common-main: call git_setup_gettext() · 5ce5f5fa
      Jeff King authored
      This should be part of every program, as otherwise users do
      not get translated error messages. However, some external
      commands forgot to do so (e.g., git-credential-store). This
      fixes them, and eliminates the repeated code in programs
      that did remember to use it.
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
    • Jeff King's avatar
      common-main: call restore_sigpipe_to_default() · 12e0437f
      Jeff King authored
      This is another safety/sanity setup that should be in force
      everywhere, but which we only applied in git.c. This did
      catch most cases, since even external commands are typically
      run via "git ..." (and the restoration applies to
      sub-processes, too). But there were cases we missed, such as
      somebody calling git-upload-pack directly via ssh, or
      scripts which use dashed external commands directly.
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
    • Jeff King's avatar
      common-main: call sanitize_stdfds() · 57f5d52a
      Jeff King authored
      This is setup that should be done in every program for
      safety, but we never got around to adding it everywhere (so
      builtins benefited from the call in git.c, but any external
      commands did not). Putting it in the common main() gives us
      this safety everywhere.
      Note that the case in daemon.c is a little funny. We wait
      until we know whether we want to daemonize, and then either:
       - call daemonize(), which will close stdio and reopen it to
         /dev/null under the hood
       - sanitize_stdfds(), to fix up any odd cases
      But that is way too late; the point of sanitizing is to give
      us reliable descriptors on 0/1/2, and we will already have
      executed code, possibly called die(), etc. The sanitizing
      should be the very first thing that happens.
      With this patch, git-daemon will sanitize first, and can
      remove the call in the non-daemonize case. It does mean that
      daemonize() may just end up closing the descriptors we
      opened, but that's not a big deal (it's not wrong to do so,
      nor is it really less optimal than the case where our parent
      process redirected us from /dev/null ahead of time).
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
    • Jeff King's avatar
      common-main: call git_extract_argv0_path() · 650c4492
      Jeff King authored
      Every program which links against libgit.a must call this
      function, or risk hitting an assert() in system_path() that
      checks whether we have configured argv0_path (though only
      when RUNTIME_PREFIX is defined, so essentially only on
      Looking at the diff, you can see that putting it into the
      common main() saves us having to do it individually in each
      of the external commands. But what you can't see are the
      cases where we _should_ have been doing so, but weren't
      (e.g., git-credential-store, and all of the t/helper test
      This has been an accident-waiting-to-happen for a long time,
      but wasn't triggered until recently because it involves one
      of those programs actually calling system_path(). That
      happened with git-credential-store in v2.8.0 with ae5f6776
      (lazily load core.sharedrepository, 2016-03-11). The
        - takes a lock file, which...
        - opens a tempfile, which...
        - calls adjust_shared_perm to fix permissions, which...
        - lazy-loads the config (as of ae5f6776), which...
        - calls system_path() to find the location of
      On systems with RUNTIME_PREFIX, this means credential-store
      reliably hits that assert() and cannot be used.
      We never noticed in the test suite, because we set
      GIT_CONFIG_NOSYSTEM there, which skips the system_path()
      lookup entirely.  But if we were to tweak git_config() to
      find /etc/gitconfig even when we aren't going to open it,
      then the test suite shows multiple failures (for
      credential-store, and for some other test helpers). I didn't
      include that tweak here because it's way too specific to
      this particular call to be worth carrying around what is
      essentially dead code.
      The implementation is fairly straightforward, with one
      exception: there is exactly one caller (git.c) that actually
      cares about the result of the function, and not the
      side-effect of setting up argv0_path. We can accommodate
      that by simply replacing the value of argv[0] in the array
      we hand down to cmd_main().
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>
    • Jeff King's avatar
      add an extra level of indirection to main() · 3f2e2297
      Jeff King authored
      There are certain startup tasks that we expect every git
      process to do. In some cases this is just to improve the
      quality of the program (e.g., setting up gettext()). In
      others it is a requirement for using certain functions in
      libgit.a (e.g., system_path() expects that you have called
      Most commands are builtins and are covered by the git.c
      version of main(). However, there are still a few external
      commands that use their own main(). Each of these has to
      remember to include the correct startup sequence, and we are
      not always consistent.
      Rather than just fix the inconsistencies, let's make this
      harder to get wrong by providing a common main() that can
      run this standard startup.
      We basically have two options to do this:
       - the compat/mingw.h file already does something like this by
         adding a #define that replaces the definition of main with a
         wrapper that calls mingw_startup().
         The upside is that the code in each program doesn't need
         to be changed at all; it's rewritten on the fly by the
         The downside is that it may make debugging of the startup
         sequence a bit more confusing, as the preprocessor is
         quietly inserting new code.
       - the builtin functions are all of the form cmd_foo(),
         and git.c's main() calls them.
         This is much more explicit, which may make things more
         obvious to somebody reading the code. It's also more
         flexible (because of course we have to figure out _which_
         cmd_foo() to call).
         The downside is that each of the builtins must define
         cmd_foo(), instead of just main().
      This patch chooses the latter option, preferring the more
      explicit approach, even though it is more invasive. We
      introduce a new file common-main.c, with the "real" main. It
      expects to call cmd_main() from whatever other objects it is
      linked against.
      We link common-main.o against anything that links against
      libgit.a, since we know that such programs will need to do
      this setup. Note that common-main.o can't actually go inside
      libgit.a, as the linker would not pick up its main()
      function automatically (it has no callers).
      The rest of the patch is just adjusting all of the various
      external programs (mostly in t/helper) to use cmd_main().
      I've provided a global declaration for cmd_main(), which
      means that all of the programs also need to match its
      signature. In particular, many functions need to switch to
      "const char **" instead of "char **" for argv. This effect
      ripples out to a few other variables and functions, as well.
      This makes the patch even more invasive, but the end result
      is much better. We should be treating argv strings as const
      anyway, and now all programs conform to the same signature
      (which also matches the way builtins are defined).
      Signed-off-by: 's avatarJeff King <peff@peff.net>
      Signed-off-by: 's avatarJunio C Hamano <gitster@pobox.com>