aboutsummaryrefslogtreecommitdiff
path: root/git-sh-setup.sh
Commit message (Collapse)AuthorAge
* 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>
* git-sh-setup.sh: make GIT_EDITOR/core.editor/VISUAL/EDITOR accept commandsDavid Kastrup2007-08-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Clean up work-tree handlingJohannes Schindelin2007-08-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Add GIT_EDITOR environment and core.editor configuration variablesAdam Roben2007-07-20
| | | | | | | | | | | 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>
* Rewrite "git-frotz" to "git frotz"Junio C Hamano2007-07-02
| | | | | | This uses the remove-dashes target to replace "git-frotz" to "git frotz". Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'js/rebase'Junio C Hamano2007-07-02
|\ | | | | | | | | | | | | | | | | | | * 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
| * Move the pick_author code to git-sh-setupJohannes Schindelin2007-06-24
| | | | | | | | | | | | | | | | | | | | 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>
* | Use new semantics of is_bare/inside_git_dir/inside_work_treeMatthias Lederhofer2007-06-06
| | | | | | | | | | | | | | | | | | | | | | | | 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>
* | rev-parse: introduce --is-bare-repositoryMatthias Lederhofer2007-06-06
|/ | | | | Signed-off-by: Matthias Lederhofer <matled@gmx.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Commands requiring a work tree must not run in GIT_DIRJohannes Schindelin2007-02-05
| | | | | | | | 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>
* [PATCH] Rename git-repo-config to git-config.Tom Prince2007-01-28
| | | | | Signed-off-by: Tom Prince <tom.prince@ualberta.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Define cd_to_toplevel shell function in git-sh-setupJunio C Hamano2007-01-12
| | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* Explain "Not a git repository: '.git'".Junio C Hamano2007-01-12
| | | | | | | | | | | | | 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>
* Disallow working directory commands in a bare repository.Shawn O. Pearce2007-01-10
| | | | | | | | | | | | | | | | 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>
* git-fetch: allow updating the current branch in a bare repository.Junio C Hamano2007-01-07
| | | | | | | | | | | | | 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>
* Use GIT_REFLOG_ACTION environment variable instead.Shawn O. Pearce2006-12-28
| | | | | | | | | | | | | | | | | 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>
* git-sh-setup: do not use repo-config to test the git directoryJunio C Hamano2006-08-11
| | | | | | | | | | 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>
* "git cmd -h" for shell scripts.Junio C Hamano2006-04-14
| | | | | | | Wrappers that use sh-setup took --help but not -h. Noticed by Sébastien Pierre. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Fix "test: unexpected operator" on bsdJunio C Hamano2006-02-12
| | | | | | This fixes the same issue as a previous fix by Alex Riesen does. Signed-off-by: Junio C Hamano <junkio@cox.net>
* Avoid using "git-var -l" until it gets fixed.Junio C Hamano2006-02-12
| | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Usage message clean-up, take #2Fredrik Kuivinen2005-12-14
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* git-sh-setup: move the repository check to a core program.Junio C Hamano2005-11-25
| | | | | | | | | | | | | | | | | 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>
* git-sh-setup: die if outside git repository.Junio C Hamano2005-11-25
| | | | | | | | 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>
* Create object subdirectories on demandLinus Torvalds2005-10-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Add git-symbolic-refJunio C Hamano2005-10-01
| | | | | | | | | | | | | 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>
* Do not require clean tree when reverting and cherry-picking.Junio C Hamano2005-09-26
| | | | | | | | | | | | | | 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>
* Fix CDPATH problem.Junio C Hamano2005-09-12
| | | | | | | | | | | | | | | | | | | 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>
* Big tool rename.Junio C Hamano2005-09-07
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>