Граф коммитов

90 Коммитов

Автор SHA1 Сообщение Дата
Junio C Hamano 8e606f97f8 Merge branch 'dw/shell-basename-dashdash-before-stripping-leading-dash-from-login'
* dw/shell-basename-dashdash-before-stripping-leading-dash-from-login:
  git-sh-setup.sh: use dashdash with basename call
2014-12-22 12:26:48 -08:00
Dan Wyand 7d665f3584 git-sh-setup.sh: use dashdash with basename call
Calling basename on a argument that starts with a dash, like a login
shell, will result in an error. Add '--' before the argument so that
the argument is interpreted properly.

Signed-off-by: Dan Wyand <danwyand@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25 10:06:08 -08:00
Junio C Hamano e96e98b339 Merge branch 'da/mergetool-tool-help'
Allow "git mergetool --help" to run outside a Git repository.

* da/mergetool-tool-help:
  difftool: don't assume that default sh is sane
  mergetool: don't require a work tree for --tool-help
  git-sh-setup: move GIT_DIR initialization into a function
  mergetool: use more conservative temporary filenames
  test-lib-functions: adjust style to match CodingGuidelines
  t7610-mergetool: prefer test_config over git config
2014-10-21 13:28:37 -07:00
David Aguilar 1c7e2d23e4 git-sh-setup: move GIT_DIR initialization into a function
Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-10-15 14:12:20 -07:00
Matthieu Moy b3275838d9 pager: remove 'S' from $LESS by default
By default, Git used to set $LESS to -FRSX if $LESS was not set by
the user. The FRX flags actually make sense for Git (F and X because
sometimes the output Git pipes to less is short, and R because Git
pipes colored output). The S flag (chop long lines), on the other
hand, is not related to Git and is a matter of user preference. Git
should not decide for the user to change LESS's default.

More specifically, the S flag harms users who review untrusted code
within a pager, since a patch looking like:

    -old code;
    +new good code; [... lots of tabs ...] malicious code;

would appear identical to:

    -old code;
    +new good code;

Users who prefer the old behavior can still set the $LESS environment
variable to -FRSX explicitly, or set core.pager to 'less -S'.

The documentation in config.txt is made a bit longer to keep both an
example setting the 'S' flag (needed to recover the old behavior)
and an example showing how to unset a flag set by Git.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-07 13:41:04 -07:00
Nicolas Vigier 51ba8ce372 git-sh-setup.sh: add variable to use the stuck-long mode
If the variable $OPTIONS_STUCKLONG is not empty, then rev-parse
option parsing is done in --stuck-long mode.

Signed-off-by: Nicolas Vigier <boklm@mars-attacks.org>
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-03 12:11:10 -08:00
Junio C Hamano 9fac0777e1 Merge branch 'jn/pager-lv-default-env'
Just like we give a reasonable default for "less" via the LESS
environment variable, specify a reasonable default for "lv" via the
"LV" environment variable when spawning the pager.

* jn/pager-lv-default-env:
  pager: set LV=-c alongside LESS=FRSX
2014-01-13 11:33:35 -08:00
Jonathan Nieder e54c1f2d25 pager: set LV=-c alongside LESS=FRSX
On systems with lv configured as the preferred pager (i.e.,
DEFAULT_PAGER=lv at build time, or PAGER=lv exported in the
environment) git commands that use color show control codes instead of
color in the pager:

	$ git diff
	^[[1mdiff --git a/.mailfilter b/.mailfilter^[[m
	^[[1mindex aa4f0b2..17e113e 100644^[[m
	^[[1m--- a/.mailfilter^[[m
	^[[1m+++ b/.mailfilter^[[m
	^[[36m@@ -1,11 +1,58 @@^[[m

"less" avoids this problem because git uses the LESS environment
variable to pass the -R option ('output ANSI color escapes in raw
form') by default.  Use the LV environment variable to pass 'lv' the
-c option ('allow ANSI escape sequences for text decoration / color')
to fix it for lv, too.

Noticed when the default value for color.ui flipped to 'auto' in
v1.8.4-rc0~36^2~1 (2013-06-10).

Reported-by: Olaf Meeuwissen <olaf.meeuwissen@avasys.jp>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-07 09:23:41 -08:00
Jonathan Nieder 11d62145b9 remove #!interpreter line from shell libraries
In a shell snippet meant to be sourced by other shell scripts, an
opening #! line does more harm than good.

The harm:

 - When the shell library is sourced, the interpreter and options from
   the #! line are not used.  Specifying a particular shell can
   confuse the reader into thinking it is safe for the shell library
   to rely on idiosyncrasies of that shell.

 - Using #! instead of a plain comment drops a helpful visual clue
   that this is a shell library and not a self-contained script.

 - Tools such as lintian can use a #! line to tell when an
   installation script has failed by forgetting to set a script
   executable.  This check does not work if shell libraries also start
   with a #! line.

The good:

 - Text editors notice the #! line and use it for syntax highlighting
   if you try to edit the installed scripts (without ".sh" suffix) in
   place.

The use of the #! for file type detection is not needed because Git's
shell libraries are meant to be edited in source form (with ".sh"
suffix).  Replace the opening #! lines with comments.

This involves tweaking the test harness's valgrind support to find
shell libraries by looking for "# " in the first line instead of "#!"
(see v1.7.6-rc3~7, 2011-06-17).

Suggested by Russ Allbery through lintian.  Thanks to Jeff King and
Clemens Buchacher for further analysis.

Tested by searching for non-executable scripts with #! line:

	find . -name .git -prune -o -type f -not -executable |
	while read file
	do
		read line <"$file"
		case $line in
		'#!'*)
			echo "$file"
			;;
		esac
	done

The only remaining scripts found are templates for shell scripts
(unimplemented.sh, wrap-for-bin.sh) and sample input used in tests
(t/t4034/perl/{pre,post}).

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-26 14:23:56 -08:00
Junio C Hamano 6c2bec96a8 Merge branch 'jc/reflog-doc'
Document rules to use GIT_REFLOG_ACTION variable in the scripted
Porcelain.  git-rebase--interactive locally violates them, but it
is a leaf user that does not call out to or dot-source other
scripts, so it does not urgently need to be fixed.

* jc/reflog-doc:
  setup_reflog_action: document the rules for using GIT_REFLOG_ACTION
2013-10-18 13:50:12 -07:00
Matthieu Moy 89b0230a20 die_with_status: use "printf '%s\n'", not "echo"
Some implementations of 'echo' (e.g. dash's built-in) interpret
backslash sequences in their arguments.

This triggered at least one bug: the error message of "rebase -i" was
turning \t in commit messages into actual tabulations. There may be
others.

Using "printf '%s\n'" instead avoids this bad behavior, and is the form
used by the "say" function.

Noticed-by: David Kastrup <dak@gnu.org>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-08-07 08:49:49 -07:00
Junio C Hamano c3e2d18996 setup_reflog_action: document the rules for using GIT_REFLOG_ACTION
The set_reflog_action helper (in git-sh-setup) is designed to be
used once at the very top of a program, like this in "git am", for
example:

	set_reflog_action am

The helper function sets the given string to GIT_REFLOG_ACTION only
when GIT_REFLOG_ACTION is not yet set.  Thanks to this, "git am",
when run as the top-level program, will use "am" in GIT_REFLOG_ACTION
and the reflog entries made by whatever it does will record the
updates of refs done by "am".

Because of the conditional assignment, when "git am" is run as a
subprogram (i.e. an implementation detail) of "git rebase" that
already sets GIT_REFLOG_ACTION to its own name, the call in "git am"
to the helper function at the beginning will *not* have any effect.

So "git rebase" can do this:

	set_reflog_action rebase
	... do its own preparation, like checking out "onto" commit
        ... decide to do "format-patch" to "am" pipeline
        	git format-patch --stdout >mbox
		git am mbox

and the reflog entries made inside "git am" invocation will say
"rebase", not "am".

Calls to "git" commands that update refs would use GIT_REFLOG_ACTION
to record who did that update.  Most such calls in scripted Porcelains
do not define custom reflog message and rely on GIT_REFLOG_ACTION to
contain its (or its caller's, when it is called as a subprogram) name.

If a scripted Porcelain wants to record a custom reflog message for
a single invocation of "git" command (e.g. when "git rebase" uses
"git checkout" to detach HEAD at the commit a series is to be
replayed on), it needs to set GIT_REFLOG_ACTION to the custom
message and export it while calling the "git" command, but such an
assignment must be restricted to that single "git" invocation and
should not be left behind to affect later codepath.

Document the rules to avoid future confusion.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-19 10:54:00 -07:00
Ramkumar Ramachandra bac1ddd0f8 sh-setup: add new peel_committish() helper
The normal way to check whether a certain revision resolves to a valid
commit is:

  $ git rev-parse --verify $REV^0

Unfortunately, this does not work when $REV is of the type :/quuxery.
Write a helper to work around this limitation.

Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-06-14 09:41:03 -07:00
Junio C Hamano 183f88018a Merge branch 'kb/p4merge'
Adjust the order mergetools feeds the files to the p4merge backend
to match the p4 convention.

* kb/p4merge:
  merge-one-file: force content conflict for "both sides added" case
  git-merge-one-file: send "ERROR:" messages to stderr
  git-merge-one-file: style cleanup
  merge-one-file: remove stale comment
  mergetools/p4merge: create a base if none available
  mergetools/p4merge: swap LOCAL and REMOTE
2013-03-26 13:15:24 -07:00
Kevin Bracey 4549162e8d mergetools/p4merge: create a base if none available
Originally, with no base, Git gave P4Merge $LOCAL as a dummy base:

   p4merge "$LOCAL" "$LOCAL" "$REMOTE" "$MERGED"

Commit 0a0ec7bd changed this to:

   p4merge "empty file" "$LOCAL" "$REMOTE" "$MERGED"

to avoid the problem of being unable to save in some circumstances with
similar inputs.

Unfortunately this approach produces much worse results on differing
inputs. P4Merge really regards the blank file as the base, and once you
have just a couple of differences between the two branches you end up
with one a massive full-file conflict. The 3-way diff is not readable,
and you have to invoke "difftool MERGE_HEAD HEAD" manually to get a
useful view.

The original approach appears to have invoked special 2-way merge
behaviour in P4Merge that occurs only if the base filename is "" or
equal to the left input.  You get a good visual comparison, and it does
not auto-resolve differences. (Normally if one branch matched the base,
it would autoresolve to the other branch).

But there appears to be no way of getting this 2-way behaviour and being
able to reliably save. Having base==left appears to be triggering other
assumptions. There are tricks the user can use to force the save icon
on, but it's not intuitive.

So we now follow a suggestion given in the original patch's discussion:
generate a virtual base, consisting of the lines common to the two
branches. This is the same as the technique used in resolve and octopus
merges, so we relocate that code to a shared function.

Note that if there are no differences at the same location, this
technique can lead to automatic resolution without conflict, combining
everything from the 2 files.  As with the other merges using this
technique, we assume the user will inspect the result before saving.

Signed-off-by: Kevin Bracey <kevin@bracey.fi>
Reviewed-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-13 10:46:07 -07:00
David Aguilar 0b54366cdd git-sh-setup: use a lowercase "usage:" string
mergetool, bisect, and other commands that use
git-sh-setup print a usage string that is inconsistent
with the rest of Git when they are invoked as "git $cmd -h".

The compiled builtins use the lowercase "usage:" string
but these commands say "Usage:".  Adjust the shell library
to make these consistent.

Signed-off-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-24 13:31:05 -08:00
Junio C Hamano 2e3c1f7a31 Merge branch 'jc/maint-fbsd-sh-ifs-workaround'
Some shells do not behave correctly when IFS is unset; work it
around by explicitly setting it to the default value.

* jc/maint-fbsd-sh-ifs-workaround:
  sh-setup: work around "unset IFS" bug in some shells
2013-01-02 10:40:41 -08:00
Junio C Hamano 393050c32b sh-setup: work around "unset IFS" bug in some shells
With an unset IFS, field splitting is supposed to act as if IFS is
set to the usual SP HT LF, but Marc Branchaud reports that the shell
on FreeBSD 7.2 gets this wrong.

It is easy to set it to the default value manually, and it is also
safer in case somebody tries to save the old value away and restore,
e.g.

	$oIFS=$IFS
	IFS=something
	...
	IFS=$oIFS

while forgetting that the original IFS might be unset (which can be
coded but would be more involved).

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-12-10 13:27:16 -08:00
Jeff King ce80ca566a git-sh-setup: refactor ident-parsing functions
The only ident-parsing function we currently provide is
get_author_ident_from_commit. This is not very
flexible for two reasons:

  1. It takes a commit as an argument, and can't read from
     commit headers saved on disk.

  2. It will only parse authors, not committers.

This patch provides a more flexible interface which will
parse multiple idents from a commit provide on stdin. We can
easily use it as a building block for the current function
to retain compatibility.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-18 15:40:13 -07:00
Junio C Hamano 72c4dbec2c Merge branch 'jc/maint-protect-sh-from-ifs'
When the user exports a non-default IFS without HT, scripts that
rely on being able to parse "ls-files -s | while read a b c..."
start to fail.  Protect them from such a misconfiguration.

* jc/maint-protect-sh-from-ifs:
  sh-setup: protect from exported IFS
2012-08-29 14:49:45 -07:00
Junio C Hamano 785063e02b sh-setup: protect from exported IFS
Many scripted Porcelains rely on being able to split words at the
default $IFS characters, i.e. SP, HT and LF.  If the user exports a
non-default IFS to the environment, what they read from plumbing
commands such as ls-files that use HT to delimit fields may not be
split in the way we expect.

Protect outselves by resetting it, just like we do so against CDPATH
exported to the environment.

Noticed by Andrew Dranse <adranse@oanda.com>.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-08 14:36:33 -07:00
Junio C Hamano 10587ce6df git-sh-setup: define workaround wrappers before they are used
Recently we tweaked this scriptlet to let mingw port redefine "pwd" to
always return Windows-style path, but the code to do so came after the
first use of "pwd" to set up $GIT_DIR shell variable.

Move the block to define these workaround wrappers, so that everything
everything that executes when the scriptlet is dot-sourced uses the
replacements.

Noticed-by: Ramsay Jones
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-05-16 10:44:04 -07:00
Ramsay Jones be39048a73 git-sh-setup.sh: Add an pwd() function for MinGW
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Acked-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-04-18 13:06:19 -07:00
Junio C Hamano 87cb3b82a4 Merge branch 'jc/parse-date-raw' into maint
* jc/parse-date-raw:
  parse_date(): '@' prefix forces git-timestamp
  parse_date(): allow ancient git-timestamp
2012-02-13 11:42:15 -08:00
Junio C Hamano 3d8bc74127 Merge branch 'jc/parse-date-raw'
* jc/parse-date-raw:
  parse_date(): '@' prefix forces git-timestamp
  parse_date(): allow ancient git-timestamp
2012-02-10 14:08:12 -08:00
Junio C Hamano 2c733fb24c parse_date(): '@' prefix forces git-timestamp
The only place that the issue this series addresses was observed
where we read "cat-file commit" output and put it in GIT_AUTHOR_DATE
in order to replay a commit with an ancient timestamp.

With the previous patch alone, "git commit --date='20100917 +0900'"
can be misinterpreted to mean an ancient timestamp, not September in
year 2010.  Guard this codepath by requring an extra '@' in front of
the raw git timestamp on the parsing side. This of course needs to
be compensated by updating get_author_ident_from_commit and the code
for "git commit --amend" to prepend '@' to the string read from the
existing commit in the GIT_AUTHOR_DATE environment variable.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-03 23:11:32 -08:00
Clemens Buchacher 87182b17ed use -h for synopsis and --help for manpage consistently
A few scripted Porcelain implementations pretend as if the routine to show
their own help messages are triggered upon "git cmd --help", but a command
line parser of "git" will hijack such a request and shows the manpage for
the cmd subcommand.

Leaving the code to handle such input is simply misleading.

Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-05 10:47:10 -07:00
Fredrik Gustafsson adb231cfda git-sh-setup: add die_with_status
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-06-13 11:23:28 -07:00
Junio C Hamano e2eb527345 require-work-tree wants more than what its name says
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>
2011-05-24 11:34:40 -07:00
Ramkumar Ramachandra 92c62a3f4f Porcelain scripts: Rewrite cryptic "needs update" error message
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-28 13:28:44 -07:00
Junio C Hamano 90d6bd5ed3 Merge branch 'uk/fix-author-ident-sed-script'
* uk/fix-author-ident-sed-script:
  get_author_ident_from_commit(): remove useless quoting
2010-10-06 12:11:12 -07:00
Pat Thoyts 5e9677cbdf git-am: fix detection of absolute paths for windows
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-10-03 23:31:59 +01:00
Uwe Kleine-König 9facb3b05b get_author_ident_from_commit(): remove useless quoting
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-09-27 10:49:49 -07:00
Junio C Hamano 9317dc4f05 Merge branch 'gb/maint-submodule-env'
* 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-07 12:47:17 -08:00
Junio C Hamano 52ebb06f14 Merge branch 'jn/maint-fix-pager'
* 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-02 12:44:11 -08:00
Junio C Hamano 8acd141bb5 Merge branch 'gf/maint-sh-setup-nongit-ok'
* gf/maint-sh-setup-nongit-ok:
  require_work_tree broken with NONGIT_OK
2010-03-02 12:44:07 -08:00
Giuseppe Bilotta 7d750f0ea5 shell setup: clear_local_git_env() function
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-24 16:24:25 -08:00
Gabriel Filion ab62677b14 require_work_tree broken with NONGIT_OK
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-17 10:55:12 -08:00
Jonathan Nieder f6dff119d5 am: Fix launching of pager
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-02-14 22:05:17 -08:00
Jonathan Nieder 46bac90458 Do not install shell libraries executable
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-31 11:53:10 -08:00
Steven Drake 91dc602de9 Use $(git rev-parse --show-toplevel) in cd_to_toplevel().
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>
2010-01-11 19:47:52 -08:00
Junio C Hamano ad7ace714d Merge branch 'rs/work-around-grep-opt-insanity'
* 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-25 11:45:07 -08:00
Junio C Hamano e1622bfcba Protect scripted Porcelains from GREP_OPTIONS insanity
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-23 16:31:07 -08:00
Jonathan Nieder b4479f0747 add -i, send-email, svn, p4, etc: use "git var GIT_EDITOR"
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-11-13 12:20:50 -08:00
Stephen Boyd e064c170b4 git-sh-setup: introduce say() for quiet options
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-18 09:50:31 -07:00
Junio C Hamano 61dbb3c441 Makefile: insert SANE_TOOL_PATH to PATH before /bin or /usr/bin
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-10 00:02:20 -07:00
Junio C Hamano 0e0aea5a47 Makefile: introduce SANE_TOOL_PATH for prepending required elements to PATH
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-06-06 13:21:51 -07:00
Marcel M. Cary 2c3c395e84 git-sh-setup: Use "cd" option, not /bin/pwd, for symlinked work tree
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-02-07 00:45:29 -08:00
Marcel M. Cary dd6c1360b2 git-sh-setup: Fix scripts whose PWD is a symlink to a work-dir on OS X
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>
2009-01-05 11:46:58 -08:00
Marcel M. Cary 08fc060865 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>
2008-12-21 01:10:48 -08:00