1. 22 Feb, 2016 1 commit
    • Jeff King's avatar
      prepare_{git,shell}_cmd: use argv_array · 20574f55
      Jeff King authored
      These functions transform an existing argv into one suitable
      for exec-ing or spawning via git or a shell. We can use an
      argv_array in each to avoid dealing with manual counting and
      allocation.
      
      This also makes the memory allocation more clear and fixes
      some leaks. In prepare_shell_cmd, we would sometimes
      allocate a new string with "$@" in it and sometimes not,
      meaning the caller could not correctly free it. On the
      non-Windows side, we are in a child process which will
      exec() or exit() immediately, so the leak isn't a big deal.
      On Windows, though, we use spawn() from the parent process,
      and leak a string for each shell command we run. On top of
      that, the Windows code did not free the allocated argv array
      at all (but does for the prepare_git_cmd case!).
      
      By switching both of these functions to write into an
      argv_array, we can consistently free the result as
      appropriate.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      20574f55
  2. 19 Feb, 2016 1 commit
  3. 22 Apr, 2015 1 commit
    • Jeff King's avatar
      stop putting argv[0] dirname at front of PATH · a0b4507e
      Jeff King authored
      When the "git" wrapper is invoked, we prepend the baked-in
      exec-path to our PATH, so that any sub-processes we exec
      will all find the git-foo commands that match the wrapper
      version.
      
      If you invoke git with an absolute path, like:
      
        /usr/bin/git foo
      
      we also prepend "/usr/bin" to the PATH. This was added long
      ago by by 231af832 (Teach the "git" command to handle some
      commands internally, 2006-02-26), with the intent that
      things would just work if you did something like:
      
        cd /opt
        tar xzf premade-git-package.tar.gz
        alias git=/opt/git/bin/git
      
      as we would then find all of the related external commands
      in /opt/git/bin. I.e., it made git runtime-relocatable,
      since at the time of 231af832, we installed all of the git
      commands into $(bindir). But these days, that is not enough.
      Since f28ac70f (Move all dashed-form commands to libexecdir,
      2007-11-28), we do not put commands into $(bindir), and you
      actually need to convert "/usr/bin" into "/usr/libexec". And
      not just for finding binaries; we want to find $(sharedir),
      etc, the same way.  The RUNTIME_PREFIX build knob does this
      the right way, by assuming a sane hierarchy rooted at
      "$prefix" when we run "$prefix/bin/git", and inferring
      "$prefix/libexec/git-core", etc.
      
      So this feature (prepending the argv[0] dirname to the PATH)
      is broken for providing a runtime prefix, and has been for
      many years. Does it do anything for other cases?
      
      For the "git" wrapper itself, as well as any commands
      shipped by "git", the answer is no. Those are already in
      git's exec-path, which is consulted first. For third-party
      commands which you've dropped into the same directory, it
      does include them. So if you do
      
        cd /opt
        tar xzf git-built-specifically-for-opt-git.tar.gz
        cp third-party/git-foo /opt/git/bin/git-foo
        alias git=/opt/git/bin/git
      
      it does mean that we will find the third-party "git-foo",
      even if you do not put /opt/git/bin into your $PATH. But
      the flipside of this is that we will bump the precedence of
      _other_ third-party tools that happen to be in the same
      directory as git. For example, consider this setup:
      
        1. Git is installed by the system in /usr/bin. There are
           other system utilities in /usr/bin. E.g., a system
           "vi".
      
        2. The user installs tools they prefer in /usr/local/bin.
           E.g., vim with a "vi" symlink. They set their PATH to
           /usr/local/bin:/usr/bin to prefer their custom tools.
      
        3. Running /usr/bin/git puts "/usr/bin" at the front of
           their PATH. When git invokes the editor on behalf of
           the user, they get the system vi, not their normal vim.
      
      There are other variants of this, including overriding
      system ruby and python (which is quite common using tools
      like "rvm" and "virtualenv", which use relocatable
      hierarchies and $PATH settings to get a consistent
      environment).
      
      Given that the main motivation for git placing the argv[0]
      dirname into the PATH has been broken for years, that the
      remaining cases are obscure and unlikely (and easily fixed
      by the user just setting up their $PATH sanely), and that
      the behavior is hurting real, reasonably common use cases,
      it's not worth continuing to do so.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Reviewed-by: default avatarJonathan Nieder <jrnieder@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      a0b4507e
  4. 01 Dec, 2014 1 commit
    • Junio C Hamano's avatar
      system_path(): always return free'able memory to the caller · 59362e56
      Junio C Hamano authored
      The function sometimes returns a newly allocated string and
      sometimes returns a borrowed string, the latter of which the callers
      must not free().  The existing callers all assume that the return
      value belongs to the callee and most of them copy it with strdup()
      when they want to keep it around.  They end up leaking the returned
      copy when the callee returned a new string because they cannot tell
      if they should free it.
      
      Change the contract between the callers and system_path() to make
      the returned string owned by the callers; they are responsible for
      freeing it when done, but they do not have to make their own copy to
      store it away.
      
      Adjust the callers to make sure they do not leak the returned string
      once they are done, but do not bother freeing it just before dying,
      exiting or exec'ing other program to avoid unnecessary churn.
      Reported-by: 0xAX's avatarAlexander Kuleshov <kuleshovmail@gmail.com>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      59362e56
  5. 26 Aug, 2014 1 commit
  6. 05 Apr, 2012 1 commit
    • Jeff King's avatar
      run-command: treat inaccessible directories as ENOENT · 38f865c2
      Jeff King authored
      When execvp reports EACCES, it can be one of two things:
      
        1. We found a file to execute, but did not have
           permissions to do so.
      
        2. We did not have permissions to look in some directory
           in the $PATH.
      
      In the former case, we want to consider this a
      permissions problem and report it to the user as such (since
      getting this for something like "git foo" is likely a
      configuration error).
      
      In the latter case, there is a good chance that the
      inaccessible directory does not contain anything of
      interest. Reporting "permission denied" is confusing to the
      user (and prevents our usual "did you mean...?" lookup). It
      also prevents git from trying alias lookup, since we do so
      only when an external command does not exist (not when it
      exists but has an error).
      
      This patch detects EACCES from execvp, checks whether we are
      in case (2), and if so converts errno to ENOENT. This
      behavior matches that of "bash" (but not of simpler shells
      that use execvp more directly, like "dash").
      
      Test stolen from Junio.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      38f865c2
  7. 17 Mar, 2011 1 commit
  8. 19 Jan, 2011 1 commit
  9. 15 Apr, 2010 1 commit
  10. 23 Feb, 2010 1 commit
    • Johannes Sixt's avatar
      Print RUNTIME_PREFIX warning only when GIT_TRACE is set · aa094570
      Johannes Sixt authored
      When RUNTIME_PREFIX is enabled, the installation prefix is derived by
      trying a limited set of known locations where the git executable can
      reside. If none of these is found, a warning is emitted.
      
      When git is built in a directory that matches neither of these known names,
      the warning would always be emitted when the uninstalled executable is run.
      This is a problem on Windows, where gitk picks the uninstalled git when
      invoked from the build directory and gets confused by the warning.
      
      Print the warning only when GIT_TRACE is set.
      Signed-off-by: default avatarJohannes Sixt <j6t@kdbg.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      aa094570
  11. 22 Mar, 2009 1 commit
    • Johannes Sixt's avatar
      Propagate --exec-path setting to external commands via GIT_EXEC_PATH · c90d565a
      Johannes Sixt authored
      Let PATH0=$PATH that was set before the invocation.
      Let /foo be a build directory.
      Let /pfx be the installation prefix.
      Let pfxexecpath=/pfx/libexec/git-core.
      
      The following is going on when 'git --exec-path=/foo gc' is invoked:
      
      1. git sets PATH=/foo:$PATH0 using the path from --exec-path
      
      2. gc execs 'git repack' (note: no dash).
      
      3. Since there is a git in /foo (it's a build directory), /foo/git is
         taken.
      
      4. No explicit exec-path is set this time, hence, this secondary git sets
         PATH=$pfxexecpath:/foo:$PATH
      
      5. Since 'repack' is not a built-in, execv_dashed_external execs
         'git-repack' (note: dash).
      
      6. There is a $pfxexecpath/git-repack, and it is taken.
      
      7. This git-repack runs 'git pack-objects' (note: no dash).
      
      8. There is no git in $pfxexecpath, but there is one in /foo. Hence,
         /foo/git is run.
      
      9. pack-objects is a builtin, hence, in effect /foo/git-pack-objects
         is run.
      
      As you can see, the way in which we previously set the PATH allowed to
      mix gits of different vintage.  By setting GIT_EXEC_PATH when --exec-path
      was given on the command line, we reduce the confusion.
      Signed-off-by: default avatarJohannes Sixt <j6t@kdbg.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      c90d565a
  12. 20 Feb, 2009 1 commit
  13. 26 Jan, 2009 5 commits
    • Steffen Prohaska's avatar
      Compute prefix at runtime if RUNTIME_PREFIX is set · 35fb0e86
      Steffen Prohaska authored
      This commit adds support for relocatable binaries (called
      RUNTIME_PREFIX).  Such binaries can be moved together with the
      system configuration files to a different directory, as long as the
      relative paths from the binary to the configuration files is
      preserved.  This functionality is essential on Windows where we
      deliver git binaries with an installer that allows to freely choose
      the installation location.
      
      If RUNTIME_PREFIX is unset we use the static prefix.  This will be
      the default on Unix.  Thus, the behavior on Unix will remain
      identical to the old implementation, which used to add the prefix
      in the Makefile.
      
      If RUNTIME_PREFIX is set the prefix is computed from the location
      of the executable.  In this case, system_path() tries to strip
      known directories that executables can be located in from the path
      of the executable.  If the path is successfully stripped it is used
      as the prefix.  For example, if the executable is
      "/msysgit/bin/git" and BINDIR is "bin", then the prefix computed is
      "/msysgit".
      
      If the runtime prefix computation fails, we fall back to the static
      prefix specified in the makefile.  This can be the case if the
      executable is not installed at a known location.  Note that our
      test system sets GIT_CONFIG_NOSYSTEM to tell git to ignore global
      configuration files during testing.  Hence testing does not trigger
      the fall back.
      
      Note that RUNTIME_PREFIX only works on Windows, though adding
      support on Unix should not be too hard.  The implementation
      requires argv0_path to be set to an absolute path.  argv0_path must
      point to the directory of the executable.  We use assert() to
      verify this in debug builds.  On Windows, the wrapper for main()
      (see compat/mingw.h) guarantees that argv0_path is correctly
      initialized.  On Unix, further work is required before
      RUNTIME_PREFIX can be enabled.
      Signed-off-by: default avatarSteffen Prohaska <prohaska@zib.de>
      Acked-by: default avatarJohannes Sixt <j6t@kdbg.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      35fb0e86
    • Steffen Prohaska's avatar
      Modify setup_path() to only add git_exec_path() to PATH · 8e346283
      Steffen Prohaska authored
      Searching git programs only in the highest priority location is
      sufficient.  It does not make sense that some of the required
      programs are located at the highest priority location but other
      programs are picked up from a lower priority exec-path.  If
      exec-path is overridden a complete set of commands should be
      provided, otherwise several different versions could get mixed,
      which is likely to cause confusion.
      
      If a user explicitly overrides the default location (by --exec-path
      or GIT_EXEC_PATH), we now expect that all the required programs are
      found there.  Instead of adding the directories "argv_exec_path",
      "getenv(EXEC_PATH_ENVIRONMENT)", and "system_path(GIT_EXEC_PATH)"
      to PATH, we now rely on git_exec_path(), which implements the same
      order, but only returns the highest priority location to search for
      executables.
      
      Accessing only the location with highest priority is also required
      for testing executables built with RUNTIME_PREFIX.  The call to
      system_path() should be avoided if RUNTIME_PREFIX is set and the
      executable is not installed at its final destination.  Because we
      test before installing, we want to avoid calling system_path()
      during tests.  The modifications in this commit avoid calling
      system_path(GIT_EXEC_PATH) if a higher-priority location is
      provided, which is the case when running the tests.
      Signed-off-by: default avatarSteffen Prohaska <prohaska@zib.de>
      Acked-by: default avatarJohannes Sixt <j6t@kdbg.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      8e346283
    • Steffen Prohaska's avatar
      git_extract_argv0_path(): Move check for valid argv0 from caller to callee · 2cd72b0b
      Steffen Prohaska authored
      This simplifies the calling code.
      Signed-off-by: default avatarSteffen Prohaska <prohaska@zib.de>
      Acked-by: default avatarJohannes Sixt <j6t@kdbg.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      2cd72b0b
    • Steve Haslam's avatar
      Refactor git_set_argv0_path() to git_extract_argv0_path() · 4dd47c3b
      Steve Haslam authored
      This commit moves the code that computes the dirname of argv[0]
      from git.c's main() to git_set_argv0_path() and renames the function
      to git_extract_argv0_path().  This makes the code in git.c's main
      less cluttered, and we can use the dirname computation from other
      main() functions too.
      
      [ spr:
       - split Steve's original commit and wrote new commit message.
       - Integrated Johannes Schindelin's
         cca17048 while rebasing onto master.
      ]
      Signed-off-by: default avatarSteve Haslam <shaslam@lastminute.com>
      Signed-off-by: default avatarSteffen Prohaska <prohaska@zib.de>
      Acked-by: default avatarJohannes Sixt <j6t@kdbg.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      4dd47c3b
    • Steffen Prohaska's avatar
      Move computation of absolute paths from Makefile to runtime (in preparation for RUNTIME_PREFIX) · 026fa0d5
      Steffen Prohaska authored
      This commit prepares the Makefile for relocatable binaries (called
      RUNTIME_PREFIX).  Such binaries will be able to be moved together
      with the system configuration files to a different directory,
      requiring to compute the prefix at runtime.
      
      In a first step, we make all paths relative in the Makefile and
      teach system_path() to add the prefix instead.  We used to compute
      absolute paths in the Makefile and passed them to C as defines.  We
      now pass relative paths to C and call system_path() to add the
      prefix at runtime.
      Signed-off-by: default avatarSteffen Prohaska <prohaska@zib.de>
      Acked-by: default avatarJohannes Sixt <j6t@kdbg.org>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      026fa0d5
  14. 12 Oct, 2008 1 commit
  15. 29 Jul, 2008 1 commit
  16. 26 Jul, 2008 4 commits
  17. 13 Jul, 2008 1 commit
    • Steffen Prohaska's avatar
      Move code interpreting path relative to exec-dir to new function system_path() · 2de9de5e
      Steffen Prohaska authored
      Expanding system paths relative to git_exec_path can be used for
      creating an installation that can be moved to a different directory
      without re-compiling.  We use this approach for template_dir and the
      system wide gitconfig.  The Windows installer (msysgit) is an example
      for such a setup.
      
      This commit moves common code to a new function system_path().  System
      paths that are to be interpreted relative to git_exec_path are passed to
      system_path() and the return value is used instead of the original path.
      system_path() prefixes a relative path with git_exec_path and leaves
      absolute paths unmodified.  For example, we now write
      
          template_dir = system_path(DEFAULT_GIT_TEMPLATE_DIR);
      
      [j6t: moved from path.c to exec_cmd.c]
      Signed-off-by: default avatarSteffen Prohaska <prohaska@zib.de>
      Signed-off-by: default avatarJohannes Sixt <johannes.sixt@telecom.at>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
      2de9de5e
  18. 26 Jun, 2008 2 commits
  19. 24 Jun, 2008 1 commit
  20. 22 Jun, 2008 1 commit
  21. 04 Dec, 2007 1 commit
  22. 30 Oct, 2007 2 commits
  23. 21 Feb, 2007 1 commit
    • Junio C Hamano's avatar
      Mechanical conversion to use prefixcmp() · cc44c765
      Junio C Hamano authored
      This mechanically converts strncmp() to use prefixcmp(), but only when
      the parameters match specific patterns, so that they can be verified
      easily.  Leftover from this will be fixed in a separate step, including
      idiotic conversions like
      
          if (!strncmp("foo", arg, 3))
      
        =>
      
          if (!(-prefixcmp(arg, "foo")))
      
      This was done by using this script in px.perl
      
         #!/usr/bin/perl -i.bak -p
         if (/strncmp\(([^,]+), "([^\\"]*)", (\d+)\)/ && (length($2) == $3)) {
                 s|strncmp\(([^,]+), "([^\\"]*)", (\d+)\)|prefixcmp($1, "$2")|;
         }
         if (/strncmp\("([^\\"]*)", ([^,]+), (\d+)\)/ && (length($1) == $3)) {
                 s|strncmp\("([^\\"]*)", ([^,]+), (\d+)\)|(-prefixcmp($2, "$1"))|;
         }
      
      and running:
      
         $ git grep -l strncmp -- '*.c' | xargs perl px.perl
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      cc44c765
  24. 19 Dec, 2006 1 commit
    • Junio C Hamano's avatar
      Use preprocessor constants for environment variable names. · d4ebc36c
      Junio C Hamano authored
      We broke the discipline Linus set up to allow compiler help us
      avoid typos in environment names in the early days of git over
      time.  This defines a handful preprocessor constants for
      environment variable names used in relatively core parts of the
      system.
      
      I've left out variable names specific to subsystems such as HTTP
      and SSL as I do not think they are big problems.
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      d4ebc36c
  25. 02 Sep, 2006 1 commit
    • Christian Couder's avatar
      Trace into a file or an open fd and refactor tracing code. · 6ce4e61f
      Christian Couder authored
      If GIT_TRACE is set to an absolute path (starting with a
      '/' character), we interpret this as a file path and we
      trace into it.
      
      Also if GIT_TRACE is set to an integer value greater than
      1 and lower than 10, we interpret this as an open fd value
      and we trace into it.
      
      Note that this behavior is not compatible with the
      previous one.
      
      We also trace whole messages using one write(2) call to
      make sure messages from processes do net get mixed up in
      the middle.
      
      This patch makes it possible to get trace information when
      running "make test".
      Signed-off-by: Christian Couder's avatarChristian Couder <chriscool@tuxfamily.org>
      Signed-off-by: default avatarJunio C Hamano <junkio@cox.net>
      6ce4e61f
  26. 31 Aug, 2006 1 commit
  27. 16 Aug, 2006 1 commit
  28. 09 Jul, 2006 2 commits
  29. 31 May, 2006 2 commits