summaryrefslogtreecommitdiff
path: root/git-sh-setup.sh
AgeCommit message (Collapse)AuthorFilesLines
2019-03-07stash: optionally use the scripted version againLibravatar Johannes Schindelin1-0/+1
We recently converted the `git stash` command from Unix shell scripts to builtins. Let's end users a way out when they discover a bug in the builtin command: `stash.useBuiltin`. As the file name `git-stash` is already in use, let's rename the scripted backend to `git-legacy-stash`. To make the test suite pass with `stash.useBuiltin=false`, this commit also backports rudimentary support for `-q` (but only *just* enough to appease the test suite), and adds a super-ugly hack to force exit code 129 for `git stash -h`. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Thomas Gummerer <t.gummerer@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-12-27Merge branch 'va/i18n-even-more'Libravatar Junio C Hamano1-2/+2
* va/i18n-even-more: i18n: fix misconversion in shell scripts
2016-12-20i18n: fix misconversion in shell scriptsLibravatar Junio C Hamano1-2/+2
An earlier series that was merged at 2703572b3a ("Merge branch 'va/i18n-even-more'", 2016-07-13) failed to use $(eval_gettext "string with \$variable interpolation") and instead used gettext in a few places, and ended up showing the variable names in the message, e.g. $ git submodule fatal: $program_name cannot be used without a working tree. Catch these mistakes with $ git grep -n '[^_]gettext .*\\\$' and fix them all to use eval_gettext instead. Reported-by: Josh Bleecher Snyder Acked-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-10-30git-sh-setup: be explicit where to dot-source git-sh-i18n from.Libravatar Anders Kaseorg1-3/+3
d323c6b641 ("i18n: git-sh-setup.sh: mark strings for translation", 2016-06-17) started to dot-source git-sh-i18n shell script library, assuming that $PATH is already adjusted for our scripts, namely, $GIT_EXEC_PATH is at the beginning of $PATH. Old contrib scripts like contrib/convert-grafts-to-replace-refs.sh and contrib/rerere-train.sh and third-party scripts like guilt may however be using this as ". $(git --exec-path)/git-sh-setup", without satisfying that assumption. Be more explicit by specifying its path prefixed with "$(git --exec-path)/". to be safe. While we’re here, move the sourcing of git-sh-i18n below the shell portability fixes. Signed-off-by: Anders Kaseorg <andersk@mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-08-08Merge branch 'ew/build-time-pager-tweaks'Libravatar Junio C Hamano1-3/+5
The build procedure learned PAGER_ENV knob that lists what default environment variable settings to export for popular pagers. This mechanism is used to tweak the default settings to MORE on FreeBSD. * ew/build-time-pager-tweaks: pager: move pager-specific setup into the build
2016-08-04pager: move pager-specific setup into the buildLibravatar Eric Wong1-3/+5
Allowing PAGER_ENV to be set at build-time allows us to move pager-specific knowledge out of our build. This allows us to set a better default for FreeBSD more(1), which pretends not to understand ANSI color escapes if the MORE environment variable is left empty, but accepts the same variables as less(1) Originally-from: https://public-inbox.org/git/xmqq61piw4yf.fsf@gitster.dls.corp.google.com/ Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Eric Wong <e@80x24.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-07-13Merge branch 'va/i18n-even-more'Libravatar Junio C Hamano1-16/+47
More markings of messages for i18n, with updates to various tests to pass GETTEXT_POISON tests. One patch from the original submission dropped due to conflicts with jk/upload-pack-hook, which is still in flux. * va/i18n-even-more: (38 commits) t5541: become resilient to GETTEXT_POISON i18n: branch: mark comment when editing branch description for translation i18n: unmark die messages for translation i18n: submodule: escape shell variables inside eval_gettext i18n: submodule: join strings marked for translation i18n: init-db: join message pieces i18n: remote: allow translations to reorder message i18n: remote: mark URL fallback text for translation i18n: standardise messages i18n: sequencer: add period to error message i18n: merge: change command option help to lowercase i18n: merge: mark messages for translation i18n: notes: mark options for translation i18n: notes: mark strings for translation i18n: transport-helper.c: change N_() call to _() i18n: bisect: mark strings for translation t5523: use test_i18ngrep for negation t4153: fix negated test_i18ngrep call t9003: become resilient to GETTEXT_POISON tests: unpack-trees: update to use test_i18n* functions ...
2016-07-11Merge branch 'lc/shell-default-value-noexpand' into maintLibravatar Junio C Hamano1-3/+3
Fix unnecessarily waste in the idiomatic use of ': ${VAR=default}' to set the default value, without enclosing it in double quotes. * lc/shell-default-value-noexpand: sh-setup: enclose setting of ${VAR=default} in double-quotes
2016-07-06Merge branch 'lc/shell-default-value-noexpand'Libravatar Junio C Hamano1-3/+3
Fix unnecessarily waste in the idiomatic use of ': ${VAR=default}' to set the default value, without enclosing it in double quotes. * lc/shell-default-value-noexpand: sh-setup: enclose setting of ${VAR=default} in double-quotes
2016-06-19sh-setup: enclose setting of ${VAR=default} in double-quotesLibravatar LE Manh Cuong1-3/+3
We often make sure an environment variable is set to something, either set by the user (in which case we do not molest it) or set it to our default value (otherwise), with : ${VAR=default value} i.e. running the no-op command ":" with ${VAR} as its parameters (or the default value we supply), relying on that ":" is a no-op. This pattern, even though it is no-op from correctness point of view, still can be expensive if the existing value in VAR has shell glob (because they will be expanded against filesystem entities) and IFS whitespaces (because the value need to be split into multiple parameters). Our invocation of ":" command does not care if the parameter given to it is after the value in VAR goes through these processing. Enclosing the whole thing in double-quote, i.e. : "${VAR=default value}" avoids paying the unnecessary cost, so let's do so. Signed-off-by: LE Manh Cuong <cuong.manhle.vn@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-17i18n: git-sh-setup.sh: mark strings for translationLibravatar Vasco Almeida1-16/+47
Positional arguments, such as $0, $1, etc, need to be stored on shell variables for use in translatable strings, according to gettext manual [1]. Add git-sh-setup.sh to LOCALIZED_SH variable in Makefile to enable extraction of string marked for translation by xgettext. Source git-sh-i18n in git-sh-setup.sh for gettext support. git-sh-setup.sh is a shell library to be sourced by other shell scripts. In order to avoid other scripts from sourcing git-sh-i18n twice, remove line that sources it from them. Not sourcing git-sh-i18n in any script that uses gettext would lead to failure due to, for instance, gettextln not being found. [1] http://www.gnu.org/software/gettext/manual/html_node/Preparing-Shell-Scripts.html Signed-off-by: Vasco Almeida <vascomalmeida@sapo.pt> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-03-10sane_grep: pass "-a" if grep accepts itLibravatar Junio C Hamano1-2/+2
Newer versions of GNU grep is reported to be pickier when we feed a non-ASCII input and break some Porcelain scripts. As we know we do not feed random binary file to our own sane_grep wrapper, allow us to always pass "-a" by setting SANE_TEXT_GREP=-a Makefile variable to work it around. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2015-05-11Merge branch 'nd/multiple-work-trees'Libravatar Junio C Hamano1-1/+1
A replacement for contrib/workdir/git-new-workdir that does not rely on symbolic links and make sharing of objects and refs safer by making the borrowee and borrowers aware of each other. * nd/multiple-work-trees: (41 commits) prune --worktrees: fix expire vs worktree existence condition t1501: fix test with split index t2026: fix broken &&-chain t2026 needs procondition SANITY git-checkout.txt: a note about multiple checkout support for submodules checkout: add --ignore-other-wortrees checkout: pass whole struct to parse_branchname_arg instead of individual flags git-common-dir: make "modules/" per-working-directory directory checkout: do not fail if target is an empty directory t2025: add a test to make sure grafts is working from a linked checkout checkout: don't require a work tree when checking out into a new one git_path(): keep "info/sparse-checkout" per work-tree count-objects: report unused files in $GIT_DIR/worktrees/... gc: support prune --worktrees gc: factor out gc.pruneexpire parsing code gc: style change -- no SP before closing parenthesis checkout: clean up half-prepared directories in --to mode checkout: reject if the branch is already checked out elsewhere prune: strategies for linked checkouts checkout: support checking out into a new working directory ...
2014-12-22Merge branch ↵Libravatar Junio C Hamano1-1/+1
'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-01git-sh-setup.sh: use rev-parse --git-path to get $GIT_DIR/objectsLibravatar Nguyễn Thái Ngọc Duy1-1/+1
If $GIT_COMMON_DIR is set, $GIT_OBJECT_DIRECTORY should be $GIT_COMMON_DIR/objects, not $GIT_DIR/objects. Just let rev-parse --git-path handle it. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-11-25git-sh-setup.sh: use dashdash with basename callLibravatar Dan Wyand1-1/+1
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-10-21Merge branch 'da/mergetool-tool-help'Libravatar Junio C Hamano1-2/+6
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-15git-sh-setup: move GIT_DIR initialization into a functionLibravatar David Aguilar1-2/+6
Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-07pager: remove 'S' from $LESS by defaultLibravatar Matthieu Moy1-1/+1
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-02-03git-sh-setup.sh: add variable to use the stuck-long modeLibravatar Nicolas Vigier1-0/+2
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-01-13Merge branch 'jn/pager-lv-default-env'Libravatar Junio C Hamano1-1/+2
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-07pager: set LV=-c alongside LESS=FRSXLibravatar Jonathan Nieder1-1/+2
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>
2013-11-26remove #!interpreter line from shell librariesLibravatar Jonathan Nieder1-6/+3
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-10-18Merge branch 'jc/reflog-doc'Libravatar Junio C Hamano1-0/+34
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-08-07die_with_status: use "printf '%s\n'", not "echo"Libravatar Matthieu Moy1-1/+1
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-06-19setup_reflog_action: document the rules for using GIT_REFLOG_ACTIONLibravatar Junio C Hamano1-0/+34
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-14sh-setup: add new peel_committish() helperLibravatar Ramkumar Ramachandra1-0/+12
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-03-26Merge branch 'kb/p4merge'Libravatar Junio C Hamano1-0/+12
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-13mergetools/p4merge: create a base if none availableLibravatar Kevin Bracey1-0/+12
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-02-24git-sh-setup: use a lowercase "usage:" stringLibravatar David Aguilar1-3/+3
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-01-02Merge branch 'jc/maint-fbsd-sh-ifs-workaround'Libravatar Junio C Hamano1-2/+5
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
2012-12-10sh-setup: work around "unset IFS" bug in some shellsLibravatar Junio C Hamano1-2/+5
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-10-18git-sh-setup: refactor ident-parsing functionsLibravatar Jeff King1-19/+43
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-08-29Merge branch 'jc/maint-protect-sh-from-ifs'Libravatar Junio C Hamano1-0/+4
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-08sh-setup: protect from exported IFSLibravatar Junio C Hamano1-0/+4
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-05-16git-sh-setup: define workaround wrappers before they are usedLibravatar Junio C Hamano1-20/+21
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-04-18git-sh-setup.sh: Add an pwd() function for MinGWLibravatar Ramsay Jones1-0/+4
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-02-13Merge branch 'jc/parse-date-raw' into maintLibravatar Junio C Hamano1-1/+1
* jc/parse-date-raw: parse_date(): '@' prefix forces git-timestamp parse_date(): allow ancient git-timestamp
2012-02-10Merge branch 'jc/parse-date-raw'Libravatar Junio C Hamano1-1/+1
* jc/parse-date-raw: parse_date(): '@' prefix forces git-timestamp parse_date(): allow ancient git-timestamp
2012-02-03parse_date(): '@' prefix forces git-timestampLibravatar Junio C Hamano1-1/+1
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>
2011-10-05use -h for synopsis and --help for manpage consistentlyLibravatar Clemens Buchacher1-1/+1
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-06-13git-sh-setup: add die_with_statusLibravatar Fredrik Gustafsson1-3/+9
This behaves similar to "die" but can exit with status different from the usual 1. Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com> Mentored-by: Jens Lehmann <Jens.Lehmann@web.de> Mentored-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-05-24require-work-tree wants more than what its name saysLibravatar Junio C Hamano1-0/+7
Somebody tried "git pull" from a random place completely outside the work tree, while exporting GIT_DIR and GIT_WORK_TREE that are set to correct places, e.g. GIT_WORK_TREE=$HOME/git.git GIT_DIR=$GIT_WORK_TREE/.git export GIT_WORK_TREE GIT_DIR cd /tmp git pull At the beginning of git-pull, we check "require-work-tree" and then "cd-to-toplevel". I _think_ the original intention when I wrote the command was "we MUST have a work tree, our $(cwd) might not be at the top-level directory of it", and no stronger than that. That check is a very sensible thing to do before doing cd-to-toplevel. We check that the place we would want to go exists, and then go there. But the implementation of require_work_tree we have today is quite different. I don't have energy to dig the history, but currently it says: test "$(git rev-parse --is-inside-work-tree 2>/dev/null)" = true || die "fatal: $0 cannot be used without a working tree." Which is completely bogus. Even though we may happen to be just outside of it right now, we may have a working tree that we can cd_to_toplevel back to. Add a function "require_work_tree_exists" that implements the check this function originally intended (this is so that third-party scripts that rely on the current behaviour do not have to get broken). For now, update _no_ in-tree scripts, not even "git pull", as nobody on the list seems to really care about the above corner case workflow that triggered this. Scripts can be updated after vetting that they do want the "we want to make sure the place we are going to go actually exists" semantics. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-28Porcelain scripts: Rewrite cryptic "needs update" error messageLibravatar Ramkumar Ramachandra1-0/+29
Although Git interally has the facility to differentiate between porcelain and plubmbing commands and appropriately print errors, several shell scripts invoke plubming commands triggering cryptic plumbing errors to be displayed on a porcelain interface. This patch replaces the "needs update" message in git-pull and git-rebase, when `git update-index` is run, with a more friendly message. Reported-by: Joshua Jensen <jjensen@workspacewhiz.com> Reported-by: Thore Husfeldt <thore.husfeldt@gmail.com> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-06Merge branch 'uk/fix-author-ident-sed-script'Libravatar Junio C Hamano1-3/+0
* uk/fix-author-ident-sed-script: get_author_ident_from_commit(): remove useless quoting
2010-10-03git-am: fix detection of absolute paths for windowsLibravatar Pat Thoyts1-0/+15
Add an is_absolute_path function to abstract out platform differences in checking for an absolute or relative path. Specifically fixes t4150-am on Windows. [PT: updated following suggestion from j6t to support \* and //*] Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
2010-09-27get_author_ident_from_commit(): remove useless quotingLibravatar Uwe Kleine-König1-3/+0
The command 's/'\''/'\''\'\'\''/g' only triples single quotes: $ echo "What's up?" | sed 's/'\''/'\''\'\'\''/g' What'''s up? This doesn't hurt as compared to a single single quote it only adds an empty string, but it makes the script needlessly complicated and hard to understand. The useful quoting is done by s/'\''/'\''\\'\'\''/g at the beginning of the script and only once for all three variables. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-07Merge branch 'gb/maint-submodule-env'Libravatar Junio C Hamano1-0/+7
* gb/maint-submodule-env: is_submodule_modified(): clear environment properly submodules: ensure clean environment when operating in a submodule shell setup: clear_local_git_env() function rev-parse: --local-env-vars option Refactor list of of repo-local env vars
2010-03-02Merge branch 'jn/maint-fix-pager'Libravatar Junio C Hamano1-0/+13
* jn/maint-fix-pager: tests: Fix race condition in t7006-pager t7006-pager: if stdout is not a terminal, make a new one tests: Add tests for automatic use of pager am: Fix launching of pager git svn: Fix launching of pager git.1: Clarify the behavior of the --paginate option Make 'git var GIT_PAGER' always print the configured pager Fix 'git var' usage synopsis
2010-03-02Merge branch 'gf/maint-sh-setup-nongit-ok'Libravatar Junio C Hamano1-1/+1
* gf/maint-sh-setup-nongit-ok: require_work_tree broken with NONGIT_OK