user/sven/git.git/environment.c, branch v1.7.3.5

setup: make sure git_dir path is in a permanent buffer, getenv(3) case

2010-11-13T00:03:27Z

getenv(3) returns not-permanent buffer which may be changed by e.g. putenv(3) call (*). In practice I've noticed this when trying to do `git commit -m abc` inside msysgit under wine, getting $ git commit -m abc fatal: could not open 'DIR=.git/COMMIT_EDITMSG': No such file or directory ^^^^ (notice introduced 'DIR=' artifact.) The problem was showing itself only with -m option, and actually, as debugging showed, originally git_dir = getenv("GIT_DIR") returned pointer to "GIT_DIR=.git\0" ^ git_dir , we stored it in git_dir, than, after processing -m git-commit option, we did setenv("GIT_EDITOR", ":") which as (*) says changed environment variables memory layout - something like this "...\0GIT_DIR=.git\0" ^ git_dir and oops - we got wrong git_dir. Avoid that by strdupping getenv("GIT_DIR") result like we did in 06f354 (setup: make sure git dir path is in a permanent buffer). Unfortunately this also shows that other getenv usage inside git needs auditing... (*) from man 3 getenv: The implementation of getenv() is not required to be reentrant. The string pointed to by the return value of getenv() may be statically allocated, and can be modified by a subsequent call to getenv(), putenv(3), setenv(3), or unsetenv(3). Cc: Jonathan Nieder Signed-off-by: Kirill Smelkov Signed-off-by: Junio C Hamano

setup: make sure git dir path is in a permanent buffer

2010-10-03T23:50:54Z

If setup_git_env() is run before the usual repository discovery sequence and .git is a file with the text gitdir: (with any string) then the in-core git_dir variable is set to the result of converting to an absolute path using make_absolute_path(). Unfortunately make_absolute_path() returns its result in a static buffer that is overwritten by later calls. Such a call could cause later accesses to git_dir (from git_pathdup(), for example) to read the wrong path, leaving git very confused. It is not obvious whether any existing code in git will trigger the problem, but in any case, it is worth a few dozen bytes to copy the return value from make_absolute_path() for some added peace of mind. Signed-off-by: Jonathan Nieder Signed-off-by: Junio C Hamano

environment.c: remove unused variable

2010-10-03T23:50:54Z

After v1.6.0-rc0~230^2^ (environment.c: remove unused function, 2008-06-19), git_refs_dir is not used any more. Signed-off-by: Jonathan Nieder Signed-off-by: Junio C Hamano

Merge branch 'kf/askpass-config'

2010-09-08T16:17:01Z

* kf/askpass-config: Extend documentation of core.askpass and GIT_ASKPASS. Allow core.askpass to override SSH_ASKPASS. Add a new option 'core.askpass'.

Merge branch 'jk/maint-pass-c-config-in-env'

2010-09-08T16:17:00Z

* jk/maint-pass-c-config-in-env: do not pass "git -c foo=bar" params to transport helpers pass "git -c foo=bar" params through environment

Add a new option 'core.askpass'.

2010-08-31T17:49:02Z

Setting this option has the same effect as setting the environment variable 'GIT_ASKPASS'. Signed-off-by: Knut Franke Signed-off-by: Junio C Hamano

do not pass "git -c foo=bar" params to transport helpers

2010-08-24T16:54:00Z

Like $GIT_CONFIG, $GIT_CONFIG_PARAMETERS needs to be suppressed by "git push" and its cousins when running local transport helpers to imitate remote transport well. Noticed-by: Jeff King Signed-off-by: Jonathan Nieder Signed-off-by: Junio C Hamano

git wrapper: introduce startup_info struct

2010-08-11T16:24:00Z

The startup_info struct will collect information managed by the git setup code, such as the prefix for relative paths passed on the command line (i.e., path to the starting cwd from the toplevel of the work tree) and whether a git repository has been found. In other words, startup_info is intended to be a collection of global variables with results that were previously returned from setup functions. This state is global anyway (since the cwd is), even if it is not currently tracked that way. Letting these values persist means there is more flexibility in deciding when to run setup. For now, the struct is empty. Signed-off-by: Nguyễn Thái Ngọc Duy Signed-off-by: Junio C Hamano Signed-off-by: Jonathan Nieder Signed-off-by: Junio C Hamano

Merge branch 'eb/core-eol'

2010-06-21T13:02:49Z

* eb/core-eol: Add "core.eol" config variable Rename the "crlf" attribute "text" Add per-repository eol normalization Add tests for per-repository eol normalization Conflicts: Documentation/config.txt Makefile

Add "core.eol" config variable

2010-06-07T04:20:04Z

Introduce a new configuration variable, "core.eol", that allows the user to set which line endings to use for end-of-line-normalized files in the working directory. It defaults to "native", which means CRLF on Windows and LF everywhere else. Note that "core.autocrlf" overrides core.eol. This means that [core] autocrlf = true puts CRLFs in the working directory even if core.eol is set to "lf". Signed-off-by: Eyvind Bernhardsen Signed-off-by: Junio C Hamano