|
|
|
#!/bin/sh
|
|
|
|
#
|
|
|
|
# This is included in commands that either have to be run from the toplevel
|
|
|
|
# of the repository, or with GIT_DIR environment variable properly.
|
|
|
|
# If the GIT_DIR does not look like the right correct git-repository,
|
|
|
|
# it dies.
|
|
|
|
|
|
|
|
# Having this variable in your environment would break scripts because
|
|
|
|
# you would cause "cd" to be taken to unexpected places. If you
|
|
|
|
# like CDPATH, define it for your interactive shell sessions without
|
|
|
|
# exporting it.
|
|
|
|
unset CDPATH
|
|
|
|
|
|
|
|
die() {
|
|
|
|
echo >&2 "$@"
|
|
|
|
exit 1
|
|
|
|
}
|
|
|
|
|
|
|
|
if test -n "$OPTIONS_SPEC"; then
|
|
|
|
usage() {
|
|
|
|
"$0" -h
|
|
|
|
exit 1
|
|
|
|
}
|
|
|
|
|
|
|
|
parseopt_extra=
|
|
|
|
[ -n "$OPTIONS_KEEPDASHDASH" ] &&
|
|
|
|
parseopt_extra="--keep-dashdash"
|
|
|
|
|
|
|
|
eval "$(
|
|
|
|
echo "$OPTIONS_SPEC" |
|
|
|
|
git rev-parse --parseopt $parseopt_extra -- "$@" ||
|
|
|
|
echo exit $?
|
|
|
|
)"
|
|
|
|
else
|
|
|
|
dashless=$(basename "$0" | sed -e 's/-/ /')
|
|
|
|
usage() {
|
|
|
|
die "Usage: $dashless $USAGE"
|
|
|
|
}
|
|
|
|
|
|
|
|
if [ -z "$LONG_USAGE" ]
|
|
|
|
then
|
|
|
|
LONG_USAGE="Usage: $dashless $USAGE"
|
|
|
|
else
|
|
|
|
LONG_USAGE="Usage: $dashless $USAGE
|
|
|
|
|
|
|
|
$LONG_USAGE"
|
|
|
|
fi
|
|
|
|
|
|
|
|
case "$1" in
|
|
|
|
-h|--h|--he|--hel|--help)
|
|
|
|
echo "$LONG_USAGE"
|
|
|
|
exit
|
|
|
|
esac
|
|
|
|
fi
|
|
|
|
|
|
|
|
set_reflog_action() {
|
|
|
|
if [ -z "${GIT_REFLOG_ACTION:+set}" ]
|
|
|
|
then
|
|
|
|
GIT_REFLOG_ACTION="$*"
|
|
|
|
export GIT_REFLOG_ACTION
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
|
|
|
git_editor() {
|
git-sh-setup.sh: make GIT_EDITOR/core.editor/VISUAL/EDITOR accept commands
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>
18 years ago
|
|
|
: "${GIT_EDITOR:=$(git config core.editor)}"
|
|
|
|
: "${GIT_EDITOR:=${VISUAL:-${EDITOR}}}"
|
|
|
|
case "$GIT_EDITOR,$TERM" in
|
|
|
|
,dumb)
|
|
|
|
echo >&2 "No editor specified in GIT_EDITOR, core.editor, VISUAL,"
|
|
|
|
echo >&2 "or EDITOR. Tried to fall back to vi but terminal is dumb."
|
|
|
|
echo >&2 "Please set one of these variables to an appropriate"
|
|
|
|
echo >&2 "editor or run $0 with options that will not cause an"
|
|
|
|
echo >&2 "editor to be invoked (e.g., -m or -F for git-commit)."
|
|
|
|
exit 1
|
|
|
|
;;
|
|
|
|
esac
|
git-sh-setup.sh: make GIT_EDITOR/core.editor/VISUAL/EDITOR accept commands
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>
18 years ago
|
|
|
eval "${GIT_EDITOR:=vi}" '"$@"'
|
|
|
|
}
|
|
|
|
|
|
|
|
is_bare_repository () {
|
|
|
|
git rev-parse --is-bare-repository
|
|
|
|
}
|
|
|
|
|
|
|
|
cd_to_toplevel () {
|
|
|
|
cdup=$(git rev-parse --show-cdup)
|
|
|
|
if test ! -z "$cdup"
|
|
|
|
then
|
git-sh-setup: Fix scripts whose PWD is a symlink into a git work-dir
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>
16 years ago
|
|
|
case "$cdup" in
|
|
|
|
/*)
|
|
|
|
# Not quite the same as if we did "cd -P '$cdup'" when
|
|
|
|
# $cdup contains ".." after symlink path components.
|
|
|
|
# Don't fix that case at least until Git switches to
|
|
|
|
# "cd -P" across the board.
|
|
|
|
phys="$cdup"
|
|
|
|
;;
|
|
|
|
..|../*|*/..|*/../*)
|
|
|
|
# Interpret $cdup relative to the physical, not logical, cwd.
|
|
|
|
# Probably /bin/pwd is more portable than passing -P to cd or pwd.
|
|
|
|
phys="$(unset PWD; /bin/pwd)/$cdup"
|
git-sh-setup: Fix scripts whose PWD is a symlink into a git work-dir
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>
16 years ago
|
|
|
;;
|
|
|
|
*)
|
|
|
|
# There's no "..", so no need to make things absolute.
|
|
|
|
phys="$cdup"
|
|
|
|
;;
|
|
|
|
esac
|
|
|
|
|
|
|
|
cd "$phys" || {
|
|
|
|
echo >&2 "Cannot chdir to $phys, the toplevel of the working tree"
|
|
|
|
exit 1
|
|
|
|
}
|
|
|
|
fi
|
|
|
|
}
|
|
|
|
|
|
|
|
require_work_tree () {
|
Clean up work-tree handling
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>
18 years ago
|
|
|
test $(git rev-parse --is-inside-work-tree) = true ||
|
|
|
|
die "fatal: $0 cannot be used without a working tree."
|
|
|
|
}
|
|
|
|
|
|
|
|
get_author_ident_from_commit () {
|
|
|
|
pick_author_script='
|
|
|
|
/^author /{
|
|
|
|
s/'\''/'\''\\'\'\''/g
|
|
|
|
h
|
|
|
|
s/^author \([^<]*\) <[^>]*> .*$/\1/
|
|
|
|
s/'\''/'\''\'\'\''/g
|
|
|
|
s/.*/GIT_AUTHOR_NAME='\''&'\''/p
|
|
|
|
|
|
|
|
g
|
|
|
|
s/^author [^<]* <\([^>]*\)> .*$/\1/
|
|
|
|
s/'\''/'\''\'\'\''/g
|
|
|
|
s/.*/GIT_AUTHOR_EMAIL='\''&'\''/p
|
|
|
|
|
|
|
|
g
|
|
|
|
s/^author [^<]* <[^>]*> \(.*\)$/\1/
|
|
|
|
s/'\''/'\''\'\'\''/g
|
|
|
|
s/.*/GIT_AUTHOR_DATE='\''&'\''/p
|
|
|
|
|
|
|
|
q
|
|
|
|
}
|
|
|
|
'
|
|
|
|
encoding=$(git config i18n.commitencoding || echo UTF-8)
|
|
|
|
git show -s --pretty=raw --encoding="$encoding" "$1" -- |
|
|
|
|
LANG=C LC_ALL=C sed -ne "$pick_author_script"
|
|
|
|
}
|
|
|
|
|
|
|
|
# Make sure we are in a valid repository of a vintage we understand,
|
|
|
|
# if we require to be in a git repository.
|
|
|
|
if test -z "$NONGIT_OK"
|
|
|
|
then
|
|
|
|
GIT_DIR=$(git rev-parse --git-dir) || exit
|
|
|
|
if [ -z "$SUBDIRECTORY_OK" ]
|
|
|
|
then
|
|
|
|
test -z "$(git rev-parse --show-cdup)" || {
|
|
|
|
exit=$?
|
|
|
|
echo >&2 "You need to run this command from the toplevel of the working tree."
|
|
|
|
exit $exit
|
|
|
|
}
|
|
|
|
fi
|
|
|
|
test -n "$GIT_DIR" && GIT_DIR=$(cd "$GIT_DIR" && pwd) || {
|
|
|
|
echo >&2 "Unable to determine absolute path of git directory"
|
|
|
|
exit 1
|
|
|
|
}
|
|
|
|
: ${GIT_OBJECT_DIRECTORY="$GIT_DIR/objects"}
|
|
|
|
fi
|
|
|
|
|
|
|
|
# Fix some commands on Windows
|
|
|
|
case $(uname -s) in
|
|
|
|
*MINGW*)
|
|
|
|
# Windows has its own (incompatible) sort and find
|
|
|
|
sort () {
|
|
|
|
/usr/bin/sort "$@"
|
|
|
|
}
|
|
|
|
find () {
|
|
|
|
/usr/bin/find "$@"
|
|
|
|
}
|
|
|
|
;;
|
|
|
|
esac
|