Граф коммитов

51 Коммитов

Автор SHA1 Сообщение Дата
Junio C Hamano 11529ecec9 Merge branch 'jk/tighten-alloc'
Update various codepaths to avoid manually-counted malloc().

* jk/tighten-alloc: (22 commits)
  ewah: convert to REALLOC_ARRAY, etc
  convert ewah/bitmap code to use xmalloc
  diff_populate_gitlink: use a strbuf
  transport_anonymize_url: use xstrfmt
  git-compat-util: drop mempcpy compat code
  sequencer: simplify memory allocation of get_message
  test-path-utils: fix normalize_path_copy output buffer size
  fetch-pack: simplify add_sought_entry
  fast-import: simplify allocation in start_packfile
  write_untracked_extension: use FLEX_ALLOC helper
  prepare_{git,shell}_cmd: use argv_array
  use st_add and st_mult for allocation size computation
  convert trivial cases to FLEX_ARRAY macros
  use xmallocz to avoid size arithmetic
  convert trivial cases to ALLOC_ARRAY
  convert manual allocations to argv_array
  argv-array: add detach function
  add helpers for allocating flex-array structs
  harden REALLOC_ARRAY and xcalloc against size_t overflow
  tree-diff: catch integer overflow in combine_diff_path allocation
  ...
2016-02-26 13:37:16 -08:00
Jeff King 20574f551b prepare_{git,shell}_cmd: use argv_array
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: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-22 14:51:09 -08:00
Alexander Kuleshov f45982337a exec_cmd.c: use find_last_dir_sep() for code simplification
We are trying to extract dirname from argv0 in the git_extract_argv0_path().
But in the same time, the <git-compat-util.h> provides find_last_dir_sep()
to get dirname from a given path.  Let's use it instead of loop for the code
simplification.

Signed-off-by: Alexander Kuleshov <kuleshovmail@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-02-19 13:26:38 -08:00
Junio C Hamano af6d7a6231 Merge branch 'jk/git-no-more-argv0-path-munging' into maint
We have prepended $GIT_EXEC_PATH and the path "git" is installed in
(typically "/usr/bin") to $PATH when invoking subprograms and hooks
for almost eternity, but the original use case the latter tried to
support was semi-bogus (i.e. install git to /opt/foo/git and run it
without having /opt/foo on $PATH), and more importantly it has
become less and less relevant as Git grew more mainstream (i.e. the
users would _want_ to have it on their $PATH).  Stop prepending the
path in which "git" is installed to users' $PATH, as that would
interfere the command search order people depend on (e.g. they may
not like versions of programs that are unrelated to Git in /usr/bin
and want to override them by having different ones in /usr/local/bin
and have the latter directory earlier in their $PATH).

* jk/git-no-more-argv0-path-munging:
  stop putting argv[0] dirname at front of PATH
2015-05-26 13:49:18 -07:00
Junio C Hamano 1645dbeff7 Merge branch 'jk/git-no-more-argv0-path-munging'
We have prepended $GIT_EXEC_PATH and the path "git" is installed in
(typically "/usr/bin") to $PATH when invoking subprograms and hooks
for almost eternity, but the original use case the latter tried to
support was semi-bogus (i.e. install git to /opt/foo/git and run it
without having /opt/foo on $PATH), and more importantly it has
become less and less relevant as Git grew more mainstream (i.e. the
users would _want_ to have it on their $PATH).  Stop prepending the
path in which "git" is installed to users' $PATH, as that would
interfere the command search order people depend on (e.g. they may
not like versions of programs that are unrelated to Git in /usr/bin
and want to override them by having different ones in /usr/local/bin
and have the latter directory earlier in their $PATH).

* jk/git-no-more-argv0-path-munging:
  stop putting argv[0] dirname at front of PATH
2015-05-19 13:17:52 -07:00
Jeff King a0b4507ef7 stop putting argv[0] dirname at front of PATH
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 231af83 (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 231af83, we installed all of the git
commands into $(bindir). But these days, that is not enough.
Since f28ac70 (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: Jeff King <peff@peff.net>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-04-22 13:41:31 -07:00
Junio C Hamano 6bcaff1a4f Merge branch 'jc/exec-cmd-system-path-leak-fix'
The function sometimes returned a non-freeable memory and some
other times returned a piece of memory that must be freed.

* jc/exec-cmd-system-path-leak-fix:
  system_path(): always return free'able memory to the caller
2014-12-22 12:27:01 -08:00
Junio C Hamano 59362e560d system_path(): always return free'able memory to the caller
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: Alexander Kuleshov <kuleshovmail@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-30 16:39:47 -08:00
René Scharfe 9610decf4d use strbuf_add_absolute_path() to add absolute paths
Signed-off-by: Rene Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-08-26 11:06:06 -07:00
Jeff King 38f865c27d run-command: treat inaccessible directories as ENOENT
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: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-05 16:24:13 -07:00
Carlos Martín Nieto e2a57aac8a Name make_*_path functions more accurately
Rename the make_*_path functions so it's clearer what they do, in
particlar make clear what the differnce between make_absolute_path and
make_nonrelative_path is by renaming them real_path and absolute_path
respectively. make_relative_path has an understandable name and is
renamed to relative_path to maintain the name convention.

The function calls have been replaced 1-to-1 in their usage.

Signed-off-by: Carlos Martín Nieto <cmn@elego.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-17 16:08:30 -07:00
Erik Faye-Lund b312b4123b exec_cmd: remove unused extern
This definition was added by commit 77cb17e9, but it's left unused since
commit 511707d. Remove the left-over definition.

Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-01-19 08:27:22 -08:00
Junio C Hamano 455bda993c Merge branch 'cw/maint-exec-defpath'
* cw/maint-exec-defpath:
  autoconf: Check if <paths.h> exists and set HAVE_PATHS_H
  exec_cmd.c: replace hard-coded path list with one from <paths.h>
2010-05-21 04:02:17 -07:00
Chris Webb cb6a22c076 exec_cmd.c: replace hard-coded path list with one from <paths.h>
The default executable path list used by exec_cmd.c is hard-coded to
be "/usr/local/bin:/usr/bin:/bin".  Use an appropriate value for the
system from <paths.h> when available.

Add HAVE_PATHS_H make variables and enable it on Linux, FreeBSD,
NetBSD, OpenBSD and GNU where it is known to exist for now. Somebody
else may want to do an autoconf support later.

Signed-off-by: Chris Webb <chris@arachsys.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-15 12:07:51 -07:00
Johannes Sixt aa0945701e Print RUNTIME_PREFIX warning only when GIT_TRACE is set
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: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-02-23 13:20:15 -08:00
Junio C Hamano b2aa958dc2 Merge branch 'js/maint-1.6.0-exec-path-env'
* js/maint-1.6.0-exec-path-env:
  Propagate --exec-path setting to external commands via GIT_EXEC_PATH
2009-03-26 00:27:03 -07:00
Johannes Sixt c90d565a46 Propagate --exec-path setting to external commands via GIT_EXEC_PATH
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: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-03-21 21:45:14 -07:00
Johannes Schindelin 024aa7d8d5 system_path(): simplify using strip_path_suffix(), and add suffix "git"
At least for the author of this patch, the logic in system_path() was
too hard to understand.  Using the function strip_path_suffix() documents
the idea of the code better.

The real change is to add the suffix "git", so that a runtime prefix will
be computed correctly even when the executable was called in /git/ as is
the case in msysGit (Windows insists to search the current directory
before the PATH when looking for an executable).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-02-19 22:47:39 -08:00
Steffen Prohaska 35fb0e8633 Compute prefix at runtime if RUNTIME_PREFIX is set
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: Steffen Prohaska <prohaska@zib.de>
Acked-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-26 00:26:05 -08:00
Steffen Prohaska 8e3462837b Modify setup_path() to only add git_exec_path() to PATH
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: Steffen Prohaska <prohaska@zib.de>
Acked-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-26 00:26:05 -08:00
Steffen Prohaska 2cd72b0b29 git_extract_argv0_path(): Move check for valid argv0 from caller to callee
This simplifies the calling code.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Acked-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-26 00:26:05 -08:00
Steve Haslam 4dd47c3b86 Refactor git_set_argv0_path() to git_extract_argv0_path()
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
   cca1704897 while rebasing onto master.
]

Signed-off-by: Steve Haslam <shaslam@lastminute.com>
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Acked-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-26 00:26:05 -08:00
Steffen Prohaska 026fa0d5ad Move computation of absolute paths from Makefile to runtime (in preparation for RUNTIME_PREFIX)
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: Steffen Prohaska <prohaska@zib.de>
Acked-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-01-26 00:26:05 -08:00
Brandon Casey f285a2d7ed Replace calls to strbuf_init(&foo, 0) with STRBUF_INIT initializer
Many call sites use strbuf_init(&foo, 0) to initialize local
strbuf variable "foo" which has not been accessed since its
declaration. These can be replaced with a static initialization
using the STRBUF_INIT macro which is just as readable, saves a
function call, and takes up fewer lines.

Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-10-12 12:36:19 -07:00
Steffen Prohaska 4933e5ebde Refactor, adding prepare_git_cmd(const char **argv)
prepare_git_cmd(const char **argv) adds a first entry "git" to
the array argv.  The new array is allocated on the heap.  It's
the caller's responsibility to release it with free().  The code
was already present in execv_git_cmd() but could not be used from
outside.  Now it can also be called for preparing the command list
in the MinGW codepath in run-command.c.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-28 23:02:11 -07:00
Johannes Sixt 10c4c881c4 Allow add_path() to add non-existent directories to the path
This function had used make_absolute_path(); but this function dies if
the directory that contains the entry whose relative path was supplied in
the argument does not exist. This is a problem if the argument is, for
example, "../libexec/git-core", and that "../libexec" does not exist.

Since the resolution of symbolic links is not required for elements in
PATH, we can fall back to using make_nonrelative_path(), which simply
prepends $PWD to the path.

We have to move make_nonrelative_path() alongside make_absolute_path() in
abspath.c so that git-shell can be linked. See 5b8e6f85f.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-25 17:41:13 -07:00
Johannes Sixt 49fa65a7a8 Allow the built-in exec path to be relative to the command invocation path
If GIT_EXEC_PATH (the macro that is defined in the Makefile) is relative,
it is interpreted relative to the command's invocation path, which usually
is $(bindir).

The Makefile rules were written with the assumption that $(gitexecdir) is
an absolute path. We introduce a separate variable that names the
(absolute) installation directory.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-25 17:41:13 -07:00
Johannes Sixt 966c6edd31 Fix relative built-in paths to be relative to the command invocation
$(gitexecdir) (as defined in the Makefile) has gained another path
component, but the relative paths in the MINGW section of the Makefile,
which are interpreted relative to it, do not account for it.

Instead of adding another ../ in front of the path, we change the code that
constructs the absolute paths to do it relative to the command's directory,
which is essentially $(bindir). We do it this way because we will also
allow a relative $(gitexecdir) later.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-25 17:41:13 -07:00
Johannes Sixt e1464ca7bb Record the command invocation path early
We will need the command invocation path in system_path(). This path was
passed to setup_path(), but  system_path() can be called earlier, for
example via:

    main
      commit_pager_choice
        setup_pager
          git_config
            git_etc_gitconfig
              system_path

Therefore, we introduce git_set_argv0_path() and call it as soon as
possible.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-25 17:41:13 -07:00
Steffen Prohaska 2de9de5e4a Move code interpreting path relative to exec-dir to new function system_path()
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: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-07-13 14:41:28 -07:00
Junio C Hamano bb1ab2db08 Merge branch 'j6t/mingw'
* j6t/mingw: (38 commits)
  compat/pread.c: Add a forward declaration to fix a warning
  Windows: Fix ntohl() related warnings about printf formatting
  Windows: TMP and TEMP environment variables specify a temporary directory.
  Windows: Make 'git help -a' work.
  Windows: Work around an oddity when a pipe with no reader is written to.
  Windows: Make the pager work.
  When installing, be prepared that template_dir may be relative.
  Windows: Use a relative default template_dir and ETC_GITCONFIG
  Windows: Compute the fallback for exec_path from the program invocation.
  Turn builtin_exec_path into a function.
  Windows: Use a customized struct stat that also has the st_blocks member.
  Windows: Add a custom implementation for utime().
  Windows: Add a new lstat and fstat implementation based on Win32 API.
  Windows: Implement a custom spawnve().
  Windows: Implement wrappers for gethostbyname(), socket(), and connect().
  Windows: Work around incompatible sort and find.
  Windows: Implement asynchronous functions as threads.
  Windows: Disambiguate DOS style paths from SSH URLs.
  Windows: A rudimentary poll() emulation.
  Windows: Implement start_command().
  ...
2008-07-02 21:57:52 -07:00
Johannes Sixt 6fad004a37 Windows: Compute the fallback for exec_path from the program invocation.
Since on Windows the user is fairly free where to install programs, we
cannot rely on a hard-coded path. We use the program name to derive the
installation directory and use that as exec_path.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
2008-06-26 08:45:12 +02:00
Johannes Sixt 4ec22a48c0 Turn builtin_exec_path into a function.
builtin_exec_path returns the hard-coded installation path, which is used
as the ultimate fallback to look for git commands. Making it into a function
enables us in a follow-up patch to return a computed value instead of just
a constant string.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
2008-06-26 08:45:12 +02:00
Junio C Hamano 7550be0a2b Prepare execv_git_cmd() for removal of builtins from the filesystem
Currently, execv_git_cmd() always try running the dashed form, which
means we cannot easily remove the git-foo hardlinks for built-in
commands.  This updates the function to always exec "git foo" form, and
makes sure "git" potty does not infinitely recurse to itself.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-06-23 22:45:41 -07:00
Johannes Sixt 80ba074f41 Windows: Use the Windows style PATH separator ';'.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
2008-06-22 11:32:45 +02:00
Christian Couder b319ce4c14 Trace and quote with argv: get rid of unneeded count argument.
Now that str_buf takes care of all the allocations, there is
no more gain to pass an argument count.

So this patch removes the "count" argument from:
	- "sq_quote_argv"
	- "trace_argv_printf"
and all the callers.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-12-03 22:11:53 -08:00
Scott R Parish 511707d42b use only the $PATH for exec'ing git commands
We need to correctly set up $PATH for non-c based git commands.
Since we already do this, we can just use that $PATH and execvp,
instead of looping over the paths with execve.

This patch adds a setup_path() function to exec_cmd.c, which sets
the $PATH order correctly for our search order. execv_git_cmd() is
stripped down to setting up argv and calling execvp(). git.c's
main() only only needs to call setup_path().

Signed-off-by: Scott R Parish <srp@srparish.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-29 20:51:37 -07:00
Scott R Parish 384df83312 "current_exec_path" is a misleading name, use "argv_exec_path"
Signed-off-by: Scott R Parish <srp@srparish.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-10-29 20:51:37 -07:00
Junio C Hamano cc44c7655f Mechanical conversion to use prefixcmp()
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: Junio C Hamano <junkio@cox.net>
2007-02-20 22:03:15 -08:00
Junio C Hamano d4ebc36c5e Use preprocessor constants for environment variable names.
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: Junio C Hamano <junkio@cox.net>
2006-12-19 01:51:51 -08:00
Christian Couder 7cf67205ca Trace into open fd and refactor tracing code.
Now 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.

It's now possible to run the tests like this:

	GIT_TRACE=9 make test 9>/var/tmp/trace.log

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-31 14:16:38 -07:00
David Rientjes 96f1e58f52 remove unnecessary initializations
[jc: I needed to hand merge the changes to the updated codebase,
 so the result needs to be checked.]

Signed-off-by: David Rientjes <rientjes@google.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-15 21:22:20 -07:00
Timo Hirvonen e82e058d3a GIT_TRACE: fix a mixed declarations and code warning
Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-09 00:57:23 -07:00
Matthias Lederhofer 575ba9d69d GIT_TRACE: show which built-in/external commands are executed
With the environment variable GIT_TRACE set git will show
 - alias expansion
 - built-in command execution
 - external command execution
on stderr.

Signed-off-by: Matthias Lederhofer <matled@gmx.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-07-09 00:57:23 -07:00
Dmitry V. Levin 2b6016263c git_exec_path, execv_git_cmd: ignore empty environment variables
Ignoring empty environment variables is good common practice.
Ignoring --exec-path with empty argument won't harm, too:
if user means current directory, there is a "--exec-path=."

Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-30 21:49:01 -07:00
Dmitry V. Levin d685990101 execv_git_cmd: Fix stack buffer overflow.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-05-30 21:47:29 -07:00
Serge E. Hallyn bb996614de cleanups: remove unused variable from exec_cmd.c
Not sure whether it should be removed, or whether
execv_git_cmd() should return it rather than -1 at bottom.

Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-17 15:06:40 -07:00
Junio C Hamano b4f2a6ac92 Use #define ARRAY_SIZE(x) (sizeof(x)/sizeof(x[0]))
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-03-09 11:58:05 -08:00
Junio C Hamano 9201c70742 Const tightening.
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: Junio C Hamano <junkio@cox.net>
2006-03-05 02:47:29 -08:00
Timo Hirvonen 962554c616 Use setenv(), fix warnings
- Fix -Wundef -Wold-style-definition warnings
  - Make pll_free() static

[jc: original patch by Timo had another unrelated bits:

  - Use setenv() instead of putenv()

 I'm postponing that part for now.]

Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-26 15:06:45 -08:00