aboutsummaryrefslogtreecommitdiff
path: root/git-sh-setup.sh
Commit message (Collapse)AuthorAge
* Merge branch 'ew/build-time-pager-tweaks'Junio C Hamano2016-08-08
|\ | | | | | | | | | | | | | | | | 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
| * pager: move pager-specific setup into the buildEric Wong2016-08-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Merge branch 'lc/shell-default-value-noexpand' into maintJunio C Hamano2016-07-11
| |\ | | | | | | | | | | | | | | | | | | | | | 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
* | \ Merge branch 'va/i18n-even-more'Junio C Hamano2016-07-13
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 ...
| * | | i18n: git-sh-setup.sh: mark strings for translationVasco Almeida2016-06-17
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Merge branch 'lc/shell-default-value-noexpand'Junio C Hamano2016-07-06
|\ \ \ | |/ / |/| / | |/ | | | | | | | | 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
| * sh-setup: enclose setting of ${VAR=default} in double-quotesLE Manh Cuong2016-06-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | sane_grep: pass "-a" if grep accepts itJunio C Hamano2016-03-10
|/ | | | | | | | | | 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>
* Merge branch 'nd/multiple-work-trees'Junio C Hamano2015-05-11
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 ...
| * git-sh-setup.sh: use rev-parse --git-path to get $GIT_DIR/objectsNguyễn Thái Ngọc Duy2014-12-01
| | | | | | | | | | | | | | | | | | 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>
* | Merge branch ↵Junio C Hamano2014-12-22
|\ \ | |/ |/| | | | | | | | | '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
| * git-sh-setup.sh: use dashdash with basename callDan Wyand2014-11-25
| | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'da/mergetool-tool-help'Junio C Hamano2014-10-21
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | 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
| * git-sh-setup: move GIT_DIR initialization into a functionDavid Aguilar2014-10-15
| | | | | | | | | | Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | pager: remove 'S' from $LESS by defaultMatthieu Moy2014-05-07
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* git-sh-setup.sh: add variable to use the stuck-long modeNicolas Vigier2014-02-03
| | | | | | | | | 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>
* Merge branch 'jn/pager-lv-default-env'Junio C Hamano2014-01-13
|\ | | | | | | | | | | | | | | | | 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
| * pager: set LV=-c alongside LESS=FRSXJonathan Nieder2014-01-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | remove #!interpreter line from shell librariesJonathan Nieder2013-11-26
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Merge branch 'jc/reflog-doc'Junio C Hamano2013-10-18
|\ | | | | | | | | | | | | | | | | | | 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
| * setup_reflog_action: document the rules for using GIT_REFLOG_ACTIONJunio C Hamano2013-06-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | die_with_status: use "printf '%s\n'", not "echo"Matthieu Moy2013-08-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | sh-setup: add new peel_committish() helperRamkumar Ramachandra2013-06-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'kb/p4merge'Junio C Hamano2013-03-26
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | 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
| * mergetools/p4merge: create a base if none availableKevin Bracey2013-03-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | git-sh-setup: use a lowercase "usage:" stringDavid Aguilar2013-02-24
|/ | | | | | | | | | | | | 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>
* Merge branch 'jc/maint-fbsd-sh-ifs-workaround'Junio C Hamano2013-01-02
|\ | | | | | | | | | | | | | | 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
| * sh-setup: work around "unset IFS" bug in some shellsJunio C Hamano2012-12-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | git-sh-setup: refactor ident-parsing functionsJeff King2012-10-18
|/ | | | | | | | | | | | | | | | | | | 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>
* Merge branch 'jc/maint-protect-sh-from-ifs'Junio C Hamano2012-08-29
|\ | | | | | | | | | | | | | | | | 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
| * sh-setup: protect from exported IFSJunio C Hamano2012-08-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
| * Merge branch 'jc/parse-date-raw' into maintJunio C Hamano2012-02-13
| |\ | | | | | | | | | | | | | | | * jc/parse-date-raw: parse_date(): '@' prefix forces git-timestamp parse_date(): allow ancient git-timestamp
* | | git-sh-setup: define workaround wrappers before they are usedJunio C Hamano2012-05-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | git-sh-setup.sh: Add an pwd() function for MinGWRamsay Jones2012-04-18
| | | | | | | | | | | | | | | | | | 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>
* | | Merge branch 'jc/parse-date-raw'Junio C Hamano2012-02-10
|\ \ \ | |/ / |/| / | |/ | | | | * jc/parse-date-raw: parse_date(): '@' prefix forces git-timestamp parse_date(): allow ancient git-timestamp
| * parse_date(): '@' prefix forces git-timestampJunio C Hamano2012-02-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | use -h for synopsis and --help for manpage consistentlyClemens Buchacher2011-10-05
|/ | | | | | | | | | | | 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>
* git-sh-setup: add die_with_statusFredrik Gustafsson2011-06-13
| | | | | | | | | | 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>
* require-work-tree wants more than what its name saysJunio C Hamano2011-05-24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Porcelain scripts: Rewrite cryptic "needs update" error messageRamkumar Ramachandra2010-10-28
| | | | | | | | | | | | | | 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>
* Merge branch 'uk/fix-author-ident-sed-script'Junio C Hamano2010-10-06
|\ | | | | | | | | * uk/fix-author-ident-sed-script: get_author_ident_from_commit(): remove useless quoting
| * get_author_ident_from_commit(): remove useless quotingUwe Kleine-König2010-09-27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | git-am: fix detection of absolute paths for windowsPat Thoyts2010-10-03
|/ | | | | | | | | | | 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>
* Merge branch 'gb/maint-submodule-env'Junio C Hamano2010-03-07
|\ | | | | | | | | | | | | | | | | * 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
| * shell setup: clear_local_git_env() functionGiuseppe Bilotta2010-02-24
| | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'jn/maint-fix-pager'Junio C Hamano2010-03-02
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * 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
| * | am: Fix launching of pagerJonathan Nieder2010-02-14
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Merge branch 'gf/maint-sh-setup-nongit-ok'Junio C Hamano2010-03-02
|\ \ | | | | | | | | | | | | * gf/maint-sh-setup-nongit-ok: require_work_tree broken with NONGIT_OK
| * | require_work_tree broken with NONGIT_OKGabriel Filion2010-02-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | | Do not install shell libraries executableJonathan Nieder2010-01-31
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
generated by cgit v1.2.1 (git 2.18.0) at 2024-12-28 01:27:16 +0000