aboutsummaryrefslogtreecommitdiff
path: root/git-sh-setup.sh
Commit message (Collapse)AuthorAge
* Merge branch 'kb/p4merge'Junio C Hamano2013-03-26
|\ | | | | | | | | | | | | | | | | | | | | | | | | Adjust the order mergetools feeds the files to the p4merge backend to match the p4 convention. * kb/p4merge: merge-one-file: force content conflict for "both sides added" case git-merge-one-file: send "ERROR:" messages to stderr git-merge-one-file: style cleanup merge-one-file: remove stale comment mergetools/p4merge: create a base if none available mergetools/p4merge: swap LOCAL and REMOTE
| * mergetools/p4merge: create a base if none availableKevin Bracey2013-03-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Originally, with no base, Git gave P4Merge $LOCAL as a dummy base: p4merge "$LOCAL" "$LOCAL" "$REMOTE" "$MERGED" Commit 0a0ec7bd changed this to: p4merge "empty file" "$LOCAL" "$REMOTE" "$MERGED" to avoid the problem of being unable to save in some circumstances with similar inputs. Unfortunately this approach produces much worse results on differing inputs. P4Merge really regards the blank file as the base, and once you have just a couple of differences between the two branches you end up with one a massive full-file conflict. The 3-way diff is not readable, and you have to invoke "difftool MERGE_HEAD HEAD" manually to get a useful view. The original approach appears to have invoked special 2-way merge behaviour in P4Merge that occurs only if the base filename is "" or equal to the left input. You get a good visual comparison, and it does not auto-resolve differences. (Normally if one branch matched the base, it would autoresolve to the other branch). But there appears to be no way of getting this 2-way behaviour and being able to reliably save. Having base==left appears to be triggering other assumptions. There are tricks the user can use to force the save icon on, but it's not intuitive. So we now follow a suggestion given in the original patch's discussion: generate a virtual base, consisting of the lines common to the two branches. This is the same as the technique used in resolve and octopus merges, so we relocate that code to a shared function. Note that if there are no differences at the same location, this technique can lead to automatic resolution without conflict, combining everything from the 2 files. As with the other merges using this technique, we assume the user will inspect the result before saving. Signed-off-by: Kevin Bracey <kevin@bracey.fi> Reviewed-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-sh-setup: use a lowercase "usage:" stringDavid Aguilar2013-02-24
|/ | | | | | | | | | | | | mergetool, bisect, and other commands that use git-sh-setup print a usage string that is inconsistent with the rest of Git when they are invoked as "git $cmd -h". The compiled builtins use the lowercase "usage:" string but these commands say "Usage:". Adjust the shell library to make these consistent. Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'jc/maint-fbsd-sh-ifs-workaround'Junio C Hamano2013-01-02
|\ | | | | | | | | | | | | | | Some shells do not behave correctly when IFS is unset; work it around by explicitly setting it to the default value. * jc/maint-fbsd-sh-ifs-workaround: sh-setup: work around "unset IFS" bug in some shells
| * sh-setup: work around "unset IFS" bug in some shellsJunio C Hamano2012-12-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With an unset IFS, field splitting is supposed to act as if IFS is set to the usual SP HT LF, but Marc Branchaud reports that the shell on FreeBSD 7.2 gets this wrong. It is easy to set it to the default value manually, and it is also safer in case somebody tries to save the old value away and restore, e.g. $oIFS=$IFS IFS=something ... IFS=$oIFS while forgetting that the original IFS might be unset (which can be coded but would be more involved). Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-sh-setup: refactor ident-parsing functionsJeff King2012-10-18
|/ | | | | | | | | | | | | | | | | | | The only ident-parsing function we currently provide is get_author_ident_from_commit. This is not very flexible for two reasons: 1. It takes a commit as an argument, and can't read from commit headers saved on disk. 2. It will only parse authors, not committers. This patch provides a more flexible interface which will parse multiple idents from a commit provide on stdin. We can easily use it as a building block for the current function to retain compatibility. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'jc/maint-protect-sh-from-ifs'Junio C Hamano2012-08-29
|\ | | | | | | | | | | | | | | | | 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 IFSJunio C Hamano2012-08-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <adranse@oanda.com>. Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * Merge branch 'jc/parse-date-raw' into maintJunio C Hamano2012-02-13
| |\ | | | | | | | | | | | | | | | * jc/parse-date-raw: parse_date(): '@' prefix forces git-timestamp parse_date(): allow ancient git-timestamp
* | | git-sh-setup: define workaround wrappers before they are usedJunio C Hamano2012-05-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <gitster@pobox.com>
* | | git-sh-setup.sh: Add an pwd() function for MinGWRamsay Jones2012-04-18
| | | | | | | | | | | | | | | | | | Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Acked-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'jc/parse-date-raw'Junio C Hamano2012-02-10
|\ \ \ | |/ / |/| / | |/ | | | | * jc/parse-date-raw: parse_date(): '@' prefix forces git-timestamp parse_date(): allow ancient git-timestamp
| * parse_date(): '@' prefix forces git-timestampJunio C Hamano2012-02-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <gitster@pobox.com>
* | use -h for synopsis and --help for manpage consistentlyClemens Buchacher2011-10-05
|/ | | | | | | | | | | | 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 <drizzd@aon.at> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-sh-setup: add die_with_statusFredrik Gustafsson2011-06-13
| | | | | | | | | | This behaves similar to "die" but can exit with status different from the usual 1. Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com> Mentored-by: Jens Lehmann <Jens.Lehmann@web.de> Mentored-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* require-work-tree wants more than what its name saysJunio C Hamano2011-05-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <gitster@pobox.com>
* Porcelain scripts: Rewrite cryptic "needs update" error messageRamkumar Ramachandra2010-10-28
| | | | | | | | | | | | | | Although Git interally has the facility to differentiate between porcelain and plubmbing commands and appropriately print errors, several shell scripts invoke plubming commands triggering cryptic plumbing errors to be displayed on a porcelain interface. This patch replaces the "needs update" message in git-pull and git-rebase, when `git update-index` is run, with a more friendly message. Reported-by: Joshua Jensen <jjensen@workspacewhiz.com> Reported-by: Thore Husfeldt <thore.husfeldt@gmail.com> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'uk/fix-author-ident-sed-script'Junio C Hamano2010-10-06
|\ | | | | | | | | * uk/fix-author-ident-sed-script: get_author_ident_from_commit(): remove useless quoting
| * get_author_ident_from_commit(): remove useless quotingUwe Kleine-König2010-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The command 's/'\''/'\''\'\'\''/g' only triples single quotes: $ echo "What's up?" | sed 's/'\''/'\''\'\'\''/g' What'''s up? This doesn't hurt as compared to a single single quote it only adds an empty string, but it makes the script needlessly complicated and hard to understand. The useful quoting is done by s/'\''/'\''\\'\'\''/g at the beginning of the script and only once for all three variables. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-am: fix detection of absolute paths for windowsPat Thoyts2010-10-03
|/ | | | | | | | | | | Add an is_absolute_path function to abstract out platform differences in checking for an absolute or relative path. Specifically fixes t4150-am on Windows. [PT: updated following suggestion from j6t to support \* and //*] Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
* Merge branch 'gb/maint-submodule-env'Junio C Hamano2010-03-07
|\ | | | | | | | | | | | | | | | | * gb/maint-submodule-env: is_submodule_modified(): clear environment properly submodules: ensure clean environment when operating in a submodule shell setup: clear_local_git_env() function rev-parse: --local-env-vars option Refactor list of of repo-local env vars
| * shell setup: clear_local_git_env() functionGiuseppe Bilotta2010-02-24
| | | | | | | | | | | | | | | | | | | | Introduce an auxiliary function to clear all repo-local environment variables. This should be invoked by any shell script that switches repository during execution, to ensure that the environment is clean and that things such as the git dir and worktree are set up correctly. Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'jn/maint-fix-pager'Junio C Hamano2010-03-02
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * jn/maint-fix-pager: tests: Fix race condition in t7006-pager t7006-pager: if stdout is not a terminal, make a new one tests: Add tests for automatic use of pager am: Fix launching of pager git svn: Fix launching of pager git.1: Clarify the behavior of the --paginate option Make 'git var GIT_PAGER' always print the configured pager Fix 'git var' usage synopsis
| * | am: Fix launching of pagerJonathan Nieder2010-02-14
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The pagination functionality in git am has some problems: - It does not check if stdout is a tty, so it always paginates. - If $GIT_PAGER uses any environment variables, they are being ignored, since it does not run $GIT_PAGER through eval. - If $GIT_PAGER is set to the empty string, instead of passing output through to stdout, it tries to run $dotest/patch. Fix them. While at it, move the definition of git_pager() to git-sh-setup so authors of other commands are not tempted to reimplement it with the same mistakes. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'gf/maint-sh-setup-nongit-ok'Junio C Hamano2010-03-02
|\ \ | | | | | | | | | | | | * gf/maint-sh-setup-nongit-ok: require_work_tree broken with NONGIT_OK
| * | require_work_tree broken with NONGIT_OKGabriel Filion2010-02-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With NONGIT_OK set, require_work_tree function outside a git repository gives a syntax error. This is caused by an incorrect use of "test" that didn't anticipate $(git rev-parse --is-inside-work-tree) may return an empty string. Properly quote the argument to "test", and send the standard error stream to /dev/null to avoid giving duplicate error messages. Signed-off-by: Gabriel Filion <lelutin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Do not install shell libraries executableJonathan Nieder2010-01-31
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | Some scripts are expected to be sourced instead of executed on their own. Avoid some confusion by not marking them executable. The executable bit was confusing the valgrind support of our test scripts, which assumed that any executable without a #!-line should be intercepted and run through valgrind. So during valgrind-enabled tests, any script sourcing these files actually sourced the valgrind interception script instead. Reported-by: Jeff King <peff@peff.net> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Use $(git rev-parse --show-toplevel) in cd_to_toplevel().Steven Drake2010-01-11
| | | | | | | | | | | | | | | | | | | | | | rev-parse --show-toplevel gives the absolute (aka "physical") path of the toplevel directory and is more portable as 'cd -P' is not supported by all shell implementations. This is also closer to what setup_work_tree() does. Signed-off-by: Steven Drake <sdrake@xnet.co.nz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'rs/work-around-grep-opt-insanity'Junio C Hamano2009-11-25
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | * rs/work-around-grep-opt-insanity: Protect scripted Porcelains from GREP_OPTIONS insanity mergetool--lib: simplify guess_merge_tool() Conflicts: git-instaweb.sh
| * | Protect scripted Porcelains from GREP_OPTIONS insanityJunio C Hamano2009-11-23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the user has exported the GREP_OPTIONS environment variable, the output from "grep" and "egrep" in scripted Porcelains may be different from what they expect. For example, we may want to count number of matching lines, by "grep" piped to "wc -l", and GREP_OPTIONS=-C3 will break such use. The approach taken by this change to address this issue is to protect only our own use of grep/egrep. Because we do not unset it at the beginning of our scripts, hook scripts run from the scripted Porcelains are exposed to the same insanity this environment variable causes when grep/egrep is used to implement logic (e.g. "grep | wc -l"), and it is entirely up to the hook scripts to protect themselves. On the other hand, applypatch-msg hook may want to show offending words in the proposed commit log message using grep to the end user, and the user might want to set GREP_OPTIONS=--color to paint the match more visibly. The approach to protect only our own use without unsetting the environment variable globally will allow this use case. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | add -i, send-email, svn, p4, etc: use "git var GIT_EDITOR"Jonathan Nieder2009-11-13
|/ / | | | | | | | | | | | | | | | | | | Use the new "git var GIT_EDITOR" feature to decide what editor to use, instead of duplicating its logic elsewhere. This should make the behavior of commands in edge cases (e.g., editor names with spaces) a little more consistent. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-sh-setup: introduce say() for quiet optionsStephen Boyd2009-06-18
| | | | | | | | | | | | | | | | | | Scripts should use say() when they want to output non-error messages. This function helps future script writers easily implement a quiet option by setting GIT_QUIET to enable suppression of non-error messages. Signed-off-by: Stephen Boyd <bebarino@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Makefile: insert SANE_TOOL_PATH to PATH before /bin or /usr/binJunio C Hamano2009-06-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In an earlier patch, we introduced SANE_TOOL_PATH that is prepended to user's PATH. This had an unintended consequence of overriding user's private binary directory that typically comes earlier in the PATH to holds even saner commands than whatever comes with the system. For example, a user may have ~/bin that is early in the path and contains a shell script "vi" that launches system's /bin/vi with specific options. Prepending SANE_TOOL_PATH to the PATH that happens to have "vi" in it defeats such customization. This fixes the issue by inserting SANE_TOOL_PATH just before /bin or /usr/bin appears on the PATH. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Makefile: introduce SANE_TOOL_PATH for prepending required elements to PATHJunio C Hamano2009-06-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some platforms (like SunOS and family) have kept their common binaries at some historical moment in time, and introduced new binaries with modern features in a special location like /usr/xpg4/bin or /usr/ucb. Some of the features provided by these modern binaries are expected and required by git. If the featureful binaries are not in the users path, then git could end up using the less featureful binary and fail. So provide a mechanism to prepend elements to the users PATH at runtime so the modern binaries will be found. Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-sh-setup: Use "cd" option, not /bin/pwd, for symlinked work treeMarcel M. Cary2009-02-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In cd_to_toplevel, instead of 'cd $(unset PWD; /bin/pwd)/$path' use 'cd -P $path'. The "-P" option yields a desirable similarity to C chdir. While the "-P" option may be slightly less commonly supported than /bin/pwd, it is more concise, better tested, and less error prone. I've already added the 'unset PWD' to fix the /bin/pwd solution on BSD; there may be more edge cases out there. This still passes all the same test cases in t5521-pull-symlink.sh and t2300-cd-to-toplevel.sh, even before updating them to use 'pwd -P'. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-sh-setup: Fix scripts whose PWD is a symlink to a work-dir on OS XMarcel M. Cary2009-01-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On Mac OS X and possibly BSDs, /bin/pwd reads PWD from the environment if available and shows the logical path by default rather than the physical one. Unset PWD before running /bin/pwd in both cd_to_toplevel and its test. Still use the external /bin/pwd because in my Bash on Linux, the builtin pwd prints the same result whether or not PWD is set. Signed-off-by: Marcel M. Cary <marcel@oak.homeunix.org> Tested-by: Wincent Colaiuta <win@wincent.com> (on Mac OS X 10.5.5) Tested-by: Marcel Koeppen <git-dev@marzelpan.de> (on Mac OS X 10.5.6) Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-sh-setup: Fix scripts whose PWD is a symlink into a git work-dirMarcel M. Cary2008-12-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I want directories of my working tree to be linked to from various paths on my filesystem where third-party components expect them, both in development and production environments. A build system's install step could solve this, but I develop scripts and web pages that don't need to be built. Git's submodule system could solve this, but we tend to develop, branch, and test those directories all in unison, so one big repository feels more natural. We prefer to edit and commit on the symlinked paths, not the canonical ones, and in that setting, "git pull" fails to find the top-level directory of the repository while other commands work fine. "git pull" fails because POSIX shells have a notion of current working directory that is different from getcwd(). The shell stores this path in PWD. As a result, "cd ../" can be interpreted differently in a shell script than chdir("../") in a C program. The shell interprets "../" by essentially stripping the last textual path component from PWD, whereas C chdir() follows the ".." link in the current directory on the filesystem. When PWD is a symlink, these are different destinations. As a result, Git's C commands find the correct top-level working tree, and shell scripts do not. Changes: * When interpreting a relative upward (../) path in cd_to_toplevel, prepend the cwd without symlinks, given by /bin/pwd * Add tests for cd_to_toplevel and "git pull" in a symlinked directory that failed before this fix, plus contrasting scenarios that already worked Signed-off-by: Marcel M. Cary <marcel@oak.homeunix.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Make usage strings dash-lessStephan Beyer2008-07-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When you misuse a git command, you are shown the usage string. But this is currently shown in the dashed form. So if you just copy what you see, it will not work, when the dashed form is no longer supported. This patch makes git commands show the dash-less version. For shell scripts that do not specify OPTIONS_SPEC, git-sh-setup.sh generates a dash-less usage string now. Signed-off-by: Stephan Beyer <s-beyer@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Windows: Work around incompatible sort and find.Johannes Sixt2008-06-26
| | | | | | | | | | | | | | | | | | If the PATH lists the Windows system directories before the MSYS directories, Windows's own incompatible sort and find commands would be picked up. We implement these commands as functions and call the real tools by absolute path. Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
* | Simplify setup of $GIT_DIR in git-sh-setup.shLars Hjemli2008-02-18
| | | | | | | | | | | | | | | | Using 'git rev-parse --git-dir' makes the code shorter and more future- proof. Signed-off-by: Lars Hjemli <hjemli@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Protect get_author_ident_from_commit() from filenames in work treeJunio C Hamano2008-02-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We used to use "cat-file commit $commit" to extract the original author information from existing commit, but an earlier commit 5ac2715 (Consistent message encoding while reusing log from an existing commit) changed it to use "git show -s $commit". If you have a file in your work tree that can be interpreted as a valid object name (e.g. "HEAD"), this conversion will not work. Disambiguate by marking the end of revision parameter on the comand line with an explicit "--" to fix this. This breakage is most visible with rebase when a file called "HEAD" exists in the worktree. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | shell-scripts usage(): consistently exit with non-zeroJunio C Hamano2007-12-20
| | | | | | | | | | | | | | | | | | Earlier conversion of shell scripts to parse-options made usage() to run "git cmd -h" which in turn emit LONG_USAGE and exit with 0 status. This is inconsistent with the scripts that do not use parse-options, whose usage() died with the message, exiting with 1. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-help: add "help.format" config variable.Christian Couder2007-12-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This config variable makes it possible to choose the default format used to display help. This format will be used only if no option like -a|--all|-i|--info|-m|--man|-w|--web is passed to "git-help". The following values are possible for this variable: - "man" --> "man" program is used - "info" --> "info" program is used - "web" --> "git-browse-help" is used By default we still show help using "man". This patch also adds -m|--man command line option to use "man" to allow overriding the "help.format" configuration variable. Note that this patch also revert some recent changes in "git-browse-help" because they prevented to look for config variables in the global configuration file. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-help -w: do not require to be in git repositoryJunio C Hamano2007-12-12
| | | | | | | | | | | | | | | | | | | | The users used to be able to say "git help cat-file" from anywhere, but the browse-help script insisted to be in a git repository, which caused "git help -w cat-file" to barf outside. Correct it. While at it, remove leftover debugging "echo". Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | sh-setup: don't let eval output to be shell-expanded.Pierre Habouzit2007-11-08
| | | | | | | | | | | | The previous patch missed the same construct in git-clone. Signed-off-by: Pierre Habouzit <madcoder@debian.org>
* | git-sh-setup: fix parseopt `eval` string underquotingJunio C Hamano2007-11-07
| | | | | | | | | | | | | | | | | | | | The 'automagic parseopt' support corrupted non option parameters that had IFS characters in them. The worst case is when it had a non option parameter like this: $1=" * some string" Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Update git-sh-setup(1) to allow transparent use of git-rev-parse --parseoptPierre Habouzit2007-11-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If you set OPTIONS_SPEC, git-sh-setups uses git-rev-parse --parseopt automatically. It also diverts usage to re-exec $0 with the -h option as parse-options.c will catch that. If you need git-rev-parse --parseopt to keep the `--` the user may have passed to your command, set OPTIONS_KEEPDASHDASH to a non empty value in your script. Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-sh-setup.sh: use "git rev-parse --show-cdup" to check for SUBDIRECTORY_OKNguyễn Thái Ngọc Duy2007-10-29
| | | | | | | | | | | | | | "git rev-parse --git-dir" trick does not play well with worktree Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-sh-setup: typofix in commentsJunio C Hamano2007-09-15
| | | | | | | | | | | | Noticed by Anupam Srivastava. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-sh-setup.sh: make GIT_DIR absoluteDavid Kastrup2007-08-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Quite a few of the scripts are rather careless about using GIT_DIR while changing directories. Some try their hands (with different likelihood of success) in making GIT_DIR absolute. This patch lets git-sh-setup.sh cater for absolute directories (in a way that should work reliably also with non-Unix path names) and removes the respective kludges in git-filter-branch.sh and git-instaweb.sh. Signed-off-by: David Kastrup <dak@gnu.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
generated by cgit v1.2.1 (git 2.18.0) at 2024-12-28 02:36:01 +0000