summaryrefslogtreecommitdiff
path: root/git-sh-setup.sh
AgeCommit message (Collapse)AuthorFilesLines
2009-02-07git-sh-setup: Use "cd" option, not /bin/pwd, for symlinked work treeLibravatar Marcel M. Cary1-21/+8
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 XLibravatar Marcel M. Cary1-1/+1
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-dirLibravatar Marcel M. Cary1-2/+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>
2008-07-13Make usage strings dash-lessLibravatar Stephan Beyer1-3/+4
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.Libravatar Johannes Sixt1-0/+13
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-18Simplify setup of $GIT_DIR in git-sh-setup.shLibravatar Lars Hjemli1-7/+1
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 treeLibravatar Junio C Hamano1-1/+1
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-zeroLibravatar Junio C Hamano1-1/+2
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-14git-help: add "help.format" config variable.Libravatar Christian Couder1-6/+1
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-12git-help -w: do not require to be in git repositoryLibravatar Junio C Hamano1-19/+26
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.Libravatar Pierre Habouzit1-5/+8
The previous patch missed the same construct in git-clone. Signed-off-by: Pierre Habouzit <madcoder@debian.org>
2007-11-07git-sh-setup: fix parseopt `eval` string underquotingLibravatar Junio C Hamano1-5/+6
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-05Update git-sh-setup(1) to allow transparent use of git-rev-parse --parseoptLibravatar Pierre Habouzit1-18/+30
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-29git-sh-setup.sh: use "git rev-parse --show-cdup" to check for SUBDIRECTORY_OKLibravatar Nguyễn Thái Ngọc Duy1-1/+1
"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 commentsLibravatar Junio C Hamano1-1/+1
Noticed by Anupam Srivastava. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2007-08-13git-sh-setup.sh: make GIT_DIR absoluteLibravatar David Kastrup1-1/+11
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-01git-sh-setup.sh: make GIT_EDITOR/core.editor/VISUAL/EDITOR accept commandsLibravatar David Kastrup1-2/+3
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 handlingLibravatar Johannes Schindelin1-2/+1
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 variablesLibravatar Adam Roben1-0/+15
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-02Rewrite "git-frotz" to "git frotz"Libravatar Junio C Hamano1-6/+6
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'Libravatar Junio C Hamano1-0/+27
* 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-24Move the pick_author code to git-sh-setupLibravatar Johannes Schindelin1-0/+27
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_treeLibravatar Matthias Lederhofer1-1/+1
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-repositoryLibravatar Matthias Lederhofer1-5/+1
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_DIRLibravatar Johannes Schindelin1-1/+2
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-28[PATCH] Rename git-repo-config to git-config.Libravatar Tom Prince1-1/+1
Signed-off-by: Tom Prince <tom.prince@ualberta.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-12Define cd_to_toplevel shell function in git-sh-setupLibravatar Junio C Hamano1-0/+11
Signed-off-by: Junio C Hamano <junkio@cox.net>
2007-01-12Explain "Not a git repository: '.git'".Libravatar Junio C Hamano1-1/+5
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.Libravatar Shawn O. Pearce1-0/+5
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-07git-fetch: allow updating the current branch in a bare repository.Libravatar Junio C Hamano1-0/+8
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>
2006-12-28Use GIT_REFLOG_ACTION environment variable instead.Libravatar Shawn O. Pearce1-0/+8
Junio rightly pointed out that the --reflog-action parameter was starting to get out of control, as most porcelain code needed to hand it to other porcelain and plumbing alike to ensure the reflog contained the top-level user action and not the lower-level actions it invoked. At Junio's suggestion we are introducing the new set_reflog_action function to all shell scripts, allowing them to declare early on what their default reflog name should be, but this setting only takes effect if the caller has not already set the GIT_REFLOG_ACTION environment variable. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-11git-sh-setup: do not use repo-config to test the git directoryLibravatar Junio C Hamano1-8/+3
Since repo-config does not fail in non-git directory, it is not a good command to use to test the git-ness nor validate the repository revision of $GIT_DIR. Original patch by Robert Shearman but with minor fixes. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-04-14"git cmd -h" for shell scripts.Libravatar Junio C Hamano1-1/+1
Wrappers that use sh-setup took --help but not -h. Noticed by Sébastien Pierre. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-12Fix "test: unexpected operator" on bsdLibravatar Junio C Hamano1-1/+1
This fixes the same issue as a previous fix by Alex Riesen does. Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-02-12Avoid using "git-var -l" until it gets fixed.Libravatar Junio C Hamano1-1/+5
This is to be nicer to people with unusable GECOS field. "git-var -l" is currently broken in that when used by a user who does not have a usable GECOS field and has not corrected it by exporting GIT_COMMITTER_NAME environment variable it dies when it tries to output GIT_COMMITTER_IDENT (same thing for AUTHOR). "git-pull" used "git-var -l" only because it needed to get a configuration variable before "git-repo-config --get" was introduced. Use the latter tool designed exactly for this purpose. "git-sh-setup" used "git-var GIT_AUTHOR_IDENT" without actually wanting to use its value. The only purpose was to cause the command to check and barf if the repository format version recorded in the $GIT_DIR/config file is too new for us to deal with correctly. Instead, use "repo-config --get" on a random property and see if it die()s, and check if the exit status is 128 (comes from die -- missing variable is reported with exit status 1, so we can tell that case apart). Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-12-14Usage message clean-up, take #2Libravatar Fredrik Kuivinen1-5/+29
There were some problems with the usage message clean-up patch series. I hadn't realised that subdirectory aware scripts can't source git-sh-setup. I propose that we change this and let the scripts which are subdirectory aware set a variable, SUBDIRECTORY_OK, before they source git-sh-setup. The scripts will also set USAGE and possibly LONG_USAGE before they source git-sh-setup. If LONG_USAGE isn't set it defaults to USAGE. If we go this way it's easy to catch --help in git-sh-setup, print the (long) usage message to stdout and exit cleanly. git-sh-setup can define a 'usage' shell function which can be called by the scripts to print the short usage string to stderr and exit non-cleanly. It will also be easy to change $0 to basename $0 or something else, if would like to do that sometime in the future. What follows is a patch to convert a couple of the commands to this style. If it's ok with everyone to do it this way I will convert the rest of the scripts too. [jc: thrown in to proposed updates queue for comments.] Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-25git-sh-setup: move the repository check to a core program.Libravatar Junio C Hamano1-7/+2
Any core commands that use setup_git_directory() now check if given GIT_DIR is really a valid repository, so the same check in git-sh-setup can use it without reimplementing it in shell. This commit changes git-sh-setup to use git-var command for that, although any other commands would do. Note that we export GIT_DIR explicitly when calling git-var; without it, the caller of this script would use GIT_DIR that we return (which is to assume ./.git unless the caller has it elsewhere) while git-var would go up to find a .git directory in our parent directories, which would be checking a different directory from what our callers will be using. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-11-25git-sh-setup: die if outside git repository.Libravatar Junio C Hamano1-6/+9
Now all the users of this script detect its exit status and die, complaining that it is outside git repository. So move the code that dies from all callers to git-sh-setup script. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-08Create object subdirectories on demandLibravatar Linus Torvalds1-1/+1
This makes it possible to have a "sparse" git object subdirectory structure, something that has become much more attractive now that people use pack-files all the time. As a result of pack-files, a git object directory doesn't necessarily have any individual objects lying around, and in that case it's just wasting space to keep the empty first-level object directories around: on many filesystems the 256 empty directories will be aboue 1MB of diskspace. Even more importantly, after you re-pack a project that _used_ to be unpacked, you could be left with huge directories that no longer contain anything, but that waste space and take time to look through. With this change, "git prune-packed" can just do an rmdir() on the directories, and they'll get removed if empty, and re-created on demand. This patch also tries to fix up "write_sha1_from_fd()" to use the new common infrastructure for creating the object files, closing a hole where we might otherwise leave half-written objects in the object database. [jc: I unoptimized the part that really removes the fan-out directories to ease transition. init-db still wastes 1MB of diskspace to hold 256 empty fan-outs, and prune-packed rmdir()'s the grown but empty directories, but runs mkdir() immediately after that -- reducing the saving from 150KB to 146KB. These parts will be re-introduced when everybody has the on-demand capability.] Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-10-01Add git-symbolic-refLibravatar Junio C Hamano1-2/+5
This adds the counterpart of git-update-ref that lets you read and create "symbolic refs". By default it uses a symbolic link to represent ".git/HEAD -> refs/heads/master", but it can be compiled to use the textfile symbolic ref. The places that did 'readlink .git/HEAD' and 'ln -s refs/heads/blah .git/HEAD' have been converted to use new git-symbolic-ref command, so that they can deal with either implementation. Signed-off-by: Junio C Hamano <junio@twinsun.com>
2005-09-26Do not require clean tree when reverting and cherry-picking.Libravatar Junio C Hamano1-11/+0
My stupidity deserved to be yelled at by Linus ... there is no reason to require the working tree to be clean when merging -- the only requirements are index to match HEAD commit and the paths involved in merge are up to date in the working tree. Revert and cherry-pick are just specialized forms of merge, and the requirements should be the same. Remove the 'general purpose routine to make sure tree is clean' from git-sh-setup, to prevent me from getting tempted again. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-12Fix CDPATH problem.Libravatar Junio C Hamano1-0/+6
CDPATH has two problems: * It takes scripts to unexpected places (somebody had CDPATH=..:../..:$HOME and the "cd" in git-clone.sh:get_repo_base took him to $HOME/.git when he said "clone foo bar" to clone a repository in "foo" which had "foo/.git"). CDPATH mechanism does not implicitly give "." at the beginning of CDPATH, which is the most irritating part. * The extra echo when it does its thing confuses scripts further. Most of our scripts that use "cd" includes git-sh-setup so the problem is primarily fixed there. git-clone starts without a repository, and it needs its own fix. Signed-off-by: Junio C Hamano <junkio@cox.net>
2005-09-07Big tool rename.Libravatar Junio C Hamano1-0/+27
As promised, this is the "big tool rename" patch. The primary differences since 0.99.6 are: (1) git-*-script are no more. The commands installed do not have any such suffix so users do not have to remember if something is implemented as a shell script or not. (2) Many command names with 'cache' in them are renamed with 'index' if that is what they mean. There are backward compatibility symblic links so that you and Porcelains can keep using the old names, but the backward compatibility support is expected to be removed in the near future. Signed-off-by: Junio C Hamano <junkio@cox.net>