user/sven/git.git/git-sh-setup.sh, branch v1.8.0.2

Merge branch 'jc/maint-protect-sh-from-ifs'

2012-08-29T21:49:45Z

When the user exports a non-default IFS without HT, scripts that rely on being able to parse "ls-files -s | while read a b c..." start to fail. Protect them from such a misconfiguration. * jc/maint-protect-sh-from-ifs: sh-setup: protect from exported IFS

sh-setup: protect from exported IFS

2012-08-08T21:36:33Z

Many scripted Porcelains rely on being able to split words at the default $IFS characters, i.e. SP, HT and LF. If the user exports a non-default IFS to the environment, what they read from plumbing commands such as ls-files that use HT to delimit fields may not be split in the way we expect. Protect outselves by resetting it, just like we do so against CDPATH exported to the environment. Noticed by Andrew Dranse . Signed-off-by: Junio C Hamano

git-sh-setup: define workaround wrappers before they are used

2012-05-16T17:44:04Z

Recently we tweaked this scriptlet to let mingw port redefine "pwd" to always return Windows-style path, but the code to do so came after the first use of "pwd" to set up $GIT_DIR shell variable. Move the block to define these workaround wrappers, so that everything everything that executes when the scriptlet is dot-sourced uses the replacements. Noticed-by: Ramsay Jones Signed-off-by: Junio C Hamano

git-sh-setup.sh: Add an pwd() function for MinGW

2012-04-18T20:06:19Z

Signed-off-by: Ramsay Jones Acked-by: Johannes Sixt Signed-off-by: Junio C Hamano

Merge branch 'jc/parse-date-raw' into maint

2012-02-13T19:42:15Z

* jc/parse-date-raw: parse_date(): '@' prefix forces git-timestamp parse_date(): allow ancient git-timestamp

Merge branch 'jc/parse-date-raw'

2012-02-10T22:08:12Z

* jc/parse-date-raw: parse_date(): '@' prefix forces git-timestamp parse_date(): allow ancient git-timestamp

parse_date(): '@' prefix forces git-timestamp

2012-02-04T07:11:32Z

The only place that the issue this series addresses was observed where we read "cat-file commit" output and put it in GIT_AUTHOR_DATE in order to replay a commit with an ancient timestamp. With the previous patch alone, "git commit --date='20100917 +0900'" can be misinterpreted to mean an ancient timestamp, not September in year 2010. Guard this codepath by requring an extra '@' in front of the raw git timestamp on the parsing side. This of course needs to be compensated by updating get_author_ident_from_commit and the code for "git commit --amend" to prepend '@' to the string read from the existing commit in the GIT_AUTHOR_DATE environment variable. Signed-off-by: Junio C Hamano

use -h for synopsis and --help for manpage consistently

2011-10-05T17:47:10Z

A few scripted Porcelain implementations pretend as if the routine to show their own help messages are triggered upon "git cmd --help", but a command line parser of "git" will hijack such a request and shows the manpage for the cmd subcommand. Leaving the code to handle such input is simply misleading. Signed-off-by: Clemens Buchacher Signed-off-by: Junio C Hamano

git-sh-setup: add die_with_status

2011-06-13T18:23:28Z

This behaves similar to "die" but can exit with status different from the usual 1. Signed-off-by: Fredrik Gustafsson Mentored-by: Jens Lehmann Mentored-by: Heiko Voigt Signed-off-by: Junio C Hamano

require-work-tree wants more than what its name says

2011-05-24T18:34:40Z

Somebody tried "git pull" from a random place completely outside the work tree, while exporting GIT_DIR and GIT_WORK_TREE that are set to correct places, e.g. GIT_WORK_TREE=$HOME/git.git GIT_DIR=$GIT_WORK_TREE/.git export GIT_WORK_TREE GIT_DIR cd /tmp git pull At the beginning of git-pull, we check "require-work-tree" and then "cd-to-toplevel". I _think_ the original intention when I wrote the command was "we MUST have a work tree, our $(cwd) might not be at the top-level directory of it", and no stronger than that. That check is a very sensible thing to do before doing cd-to-toplevel. We check that the place we would want to go exists, and then go there. But the implementation of require_work_tree we have today is quite different. I don't have energy to dig the history, but currently it says: test "$(git rev-parse --is-inside-work-tree 2>/dev/null)" = true || die "fatal: $0 cannot be used without a working tree." Which is completely bogus. Even though we may happen to be just outside of it right now, we may have a working tree that we can cd_to_toplevel back to. Add a function "require_work_tree_exists" that implements the check this function originally intended (this is so that third-party scripts that rely on the current behaviour do not have to get broken). For now, update _no_ in-tree scripts, not even "git pull", as nobody on the list seems to really care about the above corner case workflow that triggered this. Scripts can be updated after vetting that they do want the "we want to make sure the place we are going to go actually exists" semantics. Signed-off-by: Junio C Hamano