This project is mirrored from https://github.com/git/git.git. Pull mirroring updated .
  1. 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: default avatarJeff King <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      6854a8f5
  2. 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 "[email protected]" 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 <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      20574f55
  3. 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 <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      59362e56
  4. 19 Jul, 2013 1 commit
  5. 10 Jul, 2013 1 commit
  6. 26 Jan, 2009 1 commit
  7. 29 Jul, 2008 1 commit
  8. 26 Jul, 2008 1 commit
  9. 13 Jul, 2008 1 commit
    • sprohaska's avatar
      Move code interpreting path relative to exec-dir to new function system_path() · 2de9de5e
      sprohaska 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: sprohaska's avatarSteffen Prohaska <[email protected]>
      Signed-off-by: default avatarJohannes Sixt <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      2de9de5e
  10. 30 Oct, 2007 2 commits
  11. 29 Apr, 2007 1 commit
  12. 05 Mar, 2006 1 commit
    • Junio C Hamano's avatar
      Const tightening. · 9201c707
      Junio C Hamano authored
      Mark Wooding noticed there was a type mismatch warning in git.c; this
      patch does things slightly differently (mostly tightening const) and
      was what I was holding onto, waiting for the setup-revisions change
      to be merged into the master branch.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      9201c707
  13. 14 Jan, 2006 1 commit
    • Michal Ostrowski's avatar
      Exec git programs without using PATH. · 77cb17e9
      Michal Ostrowski authored
      The git suite may not be in PATH (and thus programs such as
      git-send-pack could not exec git-rev-list).  Thus there is a need for
      logic that will locate these programs.  Modifying PATH is not
      desirable as it result in behavior differing from the user's
      intentions, as we may end up prepending "/usr/bin" to PATH.
      
      - git C programs will use exec*_git_cmd() APIs to exec sub-commands.
      - exec*_git_cmd() will execute a git program by searching for it in
        the following directories:
      	1. --exec-path (as used by "git")
      	2. The GIT_EXEC_PATH environment variable.
      	3. $(gitexecdir) as set in Makefile (default value $(bindir)).
      - git wrapper will modify PATH as before to enable shell scripts to
        invoke "git-foo" commands.
      
      Ideally, shell scripts should use the git wrapper to become independent
      of PATH, and then modifying PATH will not be necessary.
      
      [jc: with minor updates after a brief review.]
      Signed-off-by: default avatarMichal Ostrowski <[email protected]ibm.com>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      77cb17e9