summaryrefslogtreecommitdiff
path: root/git-sh-setup.sh
AgeCommit message (Collapse)Author
2011-06-13git-sh-setup: add die_with_statusFredrik Gustafsson
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>
2011-05-24require-work-tree wants more than what its name saysJunio C Hamano
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>
2010-10-28Porcelain scripts: Rewrite cryptic "needs update" error messageRamkumar Ramachandra
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>
2010-10-06Merge branch 'uk/fix-author-ident-sed-script'Junio C Hamano
* uk/fix-author-ident-sed-script: get_author_ident_from_commit(): remove useless quoting
2010-10-03git-am: fix detection of absolute paths for windowsPat Thoyts
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>
2010-09-27get_author_ident_from_commit(): remove useless quotingUwe Kleine-König
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>
2010-03-07Merge branch 'gb/maint-submodule-env'Junio C Hamano
* 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
2010-03-02Merge branch 'jn/maint-fix-pager'Junio C Hamano
* 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
2010-03-02Merge branch 'gf/maint-sh-setup-nongit-ok'Junio C Hamano
* gf/maint-sh-setup-nongit-ok: require_work_tree broken with NONGIT_OK
2010-02-25shell setup: clear_local_git_env() functionGiuseppe Bilotta
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>
2010-02-17require_work_tree broken with NONGIT_OKGabriel Filion
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>
2010-02-15am: Fix launching of pagerJonathan Nieder
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>
2010-01-31Do not install shell libraries executableJonathan Nieder
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>
2010-01-12Use $(git rev-parse --show-toplevel) in cd_to_toplevel().Steven Drake
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>
2009-11-25Merge branch 'rs/work-around-grep-opt-insanity'Junio C Hamano
* rs/work-around-grep-opt-insanity: Protect scripted Porcelains from GREP_OPTIONS insanity mergetool--lib: simplify guess_merge_tool() Conflicts: git-instaweb.sh
2009-11-24Protect scripted Porcelains from GREP_OPTIONS insanityJunio C Hamano
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>
2009-11-13add -i, send-email, svn, p4, etc: use "git var GIT_EDITOR"Jonathan Nieder
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>
2009-06-18git-sh-setup: introduce say() for quiet optionsStephen Boyd
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>
2009-06-10Makefile: insert SANE_TOOL_PATH to PATH before /bin or /usr/binJunio C Hamano
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>
2009-06-06Makefile: introduce SANE_TOOL_PATH for prepending required elements to PATHJunio C Hamano
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>
2009-02-07git-sh-setup: Use "cd" option, not /bin/pwd, for symlinked work treeMarcel M. Cary
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>
2009-01-05git-sh-setup: Fix scripts whose PWD is a symlink to a work-dir on OS XMarcel M. Cary
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>
2008-12-21git-sh-setup: Fix scripts whose PWD is a symlink into a git work-dirMarcel M. Cary
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>
2008-07-13Make usage strings dash-lessStephan Beyer
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>
2008-06-26Windows: Work around incompatible sort and find.Johannes Sixt
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>
2008-02-19Simplify setup of $GIT_DIR in git-sh-setup.shLars Hjemli
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>
2008-02-13Protect get_author_ident_from_commit() from filenames in work treeJunio C Hamano
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>
2007-12-20shell-scripts usage(): consistently exit with non-zeroJunio C Hamano
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>
2007-12-15git-help: add "help.format" config variable.Christian Couder
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>
2007-12-13git-help -w: do not require to be in git repositoryJunio C Hamano
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>
2007-11-08sh-setup: don't let eval output to be shell-expanded.Pierre Habouzit
The previous patch missed the same construct in git-clone. Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2007-11-08git-sh-setup: fix parseopt `eval` string underquotingJunio C Hamano
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>
2007-11-06Update git-sh-setup(1) to allow transparent use of git-rev-parse --parseoptPierre Habouzit
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>
2007-10-30git-sh-setup.sh: use "git rev-parse --show-cdup" to check for SUBDIRECTORY_OKNguyễn Thái Ngọc Duy
"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>
2007-09-15git-sh-setup: typofix in commentsJunio C Hamano
Noticed by Anupam Srivastava. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-14git-sh-setup.sh: make GIT_DIR absoluteDavid Kastrup
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>
2007-08-02git-sh-setup.sh: make GIT_EDITOR/core.editor/VISUAL/EDITOR accept commandsDavid Kastrup
The previous code only allowed specifying a single executable rather than a complete command like "emacsclient --alternate-editor vi" in those variables. Since VISUAL/EDITOR appear to be traditionally passed to a shell for interpretation (as corroborated with "less", "mail" and "mailx", while the really ancient "more" indeed allows only an executable name), the shell function git_editor has been amended appropriately. "eval" is employed to have quotes and similar interpreted _after_ expansion, so that specifying EDITOR='"/home/dak/My Commands/notepad.exe"' can be used for actually using commands with blanks. Instead of passing just the first argument of git_editor on, we pass all of them (so that +lineno might be employed at a later point of time, or so that multiple files may be edited when appropriate). Strictly speaking, there is a change in behavior: when git config core.editor returns a valid but empty string, the fallbacks are still searched. This is more consistent, and the old code was problematic with regard to multiple blanks. Putting in additional quotes might have worked, but quotes inside of command substitution inside of quotes is nasty enough to not reliably work the same across "Bourne shells". Signed-off-by: David Kastrup <dak@gnu.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-01Clean up work-tree handlingJohannes Schindelin
The old version of work-tree support was an unholy mess, barely readable, and not to the point. For example, why do you have to provide a worktree, when it is not used? As in "git status". Now it works. Another riddle was: if you can have work trees inside the git dir, why are some programs complaining that they need a work tree? IOW it is allowed to call $ git --git-dir=../ --work-tree=. bla when you really want to. In this case, you are both in the git directory and in the working tree. So, programs have to actually test for the right thing, namely if they are inside a working tree, and not if they are inside a git directory. Also, GIT_DIR=../.git should behave the same as if no GIT_DIR was specified, unless there is a repository in the current working directory. It does now. The logic to determine if a repository is bare, or has a work tree (tertium non datur), is this: --work-tree=bla overrides GIT_WORK_TREE, which overrides core.bare = true, which overrides core.worktree, which overrides GIT_DIR/.. when GIT_DIR ends in /.git, which overrides the directory in which .git/ was found. In related news, a long standing bug was fixed: when in .git/bla/x.git/, which is a bare repository, git formerly assumed ../.. to be the appropriate git dir. This problem was reported by Shawn Pearce to have caused much pain, where a colleague mistakenly ran "git init" in "/" a long time ago, and bare repositories just would not work. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-20Add GIT_EDITOR environment and core.editor configuration variablesAdam Roben
These variables let you specify an editor that will be launched in preference to the EDITOR and VISUAL environment variables. The order of preference is GIT_EDITOR, core.editor, EDITOR, VISUAL. [jc: added a test and config variable documentation] Signed-off-by: Adam Roben <aroben@apple.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-03Rewrite "git-frotz" to "git frotz"Junio C Hamano
This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-07-02Merge branch 'js/rebase'Junio C Hamano
* js/rebase: Teach rebase -i about --preserve-merges rebase -i: provide reasonable reflog for the rebased branch rebase -i: several cleanups ignore git-rebase--interactive Teach rebase an interactive mode Move the pick_author code to git-sh-setup
2007-06-25Move the pick_author code to git-sh-setupJohannes Schindelin
At the moment, only git-commit uses that code, to pick the author name, email and date from a given commit. This code will be reused in git rebase --interactive. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-06Use new semantics of is_bare/inside_git_dir/inside_work_treeMatthias Lederhofer
Up to now to check for a working tree this was used: !is_bare && !inside_git_dir (the check for bare is redundant because is_inside_git_dir returned already 1 for bare repositories). Now the check is: inside_work_tree && !inside_git_dir Signed-off-by: Matthias Lederhofer <matled@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-06-06rev-parse: introduce --is-bare-repositoryMatthias Lederhofer
Signed-off-by: Matthias Lederhofer <matled@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-02-05Commands requiring a work tree must not run in GIT_DIRJohannes Schindelin
This patch helps when you accidentally run something like git-clean in the git directory instead of the work tree. Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-29[PATCH] Rename git-repo-config to git-config.Tom Prince
Signed-off-by: Tom Prince <tom.prince@ualberta.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-13Define cd_to_toplevel shell function in git-sh-setupJunio C Hamano
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-12Explain "Not a git repository: '.git'".Junio C Hamano
Andy Parkins noticed that the error message some "whole tree" oriented commands emit is stated misleadingly when they refused to run from a subdirectory. We could probably allow some of them to work from a subdirectory but that is a semantic change that could have unintended side effects, so let's start at first by rewording the error message to be easier to read without doing anything else to be safe. Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-10Disallow working directory commands in a bare repository.Shawn O. Pearce
If the user tries to run a porcelainish command which requires a working directory in a bare repository they may get unexpected results which are difficult to predict and may differ from command to command. Instead we should detect that the current repository is a bare repository and refuse to run the command there, as there is no working directory associated with it. [jc: updated Shawn's original somewhat -- bugs are mine.] Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-08git-fetch: allow updating the current branch in a bare repository.Junio C Hamano
Sometimes, people have only fetch access into a bare repository that is used as a back-up location (or a distribution point) but does not have a push access for networking reasons, e.g. one end being behind a firewall, and updating the "current branch" in such a case is perfectly fine. This allows such a fetch without --update-head-ok, which is a flag that should never be used by end users otherwise. Signed-off-by: Junio C Hamano <junkio@cox.net>