We do that almost everywhere, because it's faster for large number of
refs, see a31e62629 (completion: optimize refs completion, 2011-10-15).
These were the last two places where we still used __gitcomp() for
completing refs.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The __git_ps1() prompt function would not show an untracked state
when all the untracked files are outside the current working
directory.
Signed-off-by: Cody A Taylor <codemister99@yahoo.com>
Helped-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current definition results in an incorrect expansion of the term under zsh.
For instance "/^${1////\\/}/" under zsh with the argument "hi" results in:
/^/\/h/\/i/
This results in an output similar to this when trying to complete `git grep
chartab` under zsh:
:: git grep chartabawk: cmd. line:1: /^/\/c/\/h/\/a/\/r/\/t/\/a/\/b/ { print $1 }
awk: cmd. line:1: ^ backslash not last character on line
awk: cmd. line:1: /^/\/c/\/h/\/a/\/r/\/t/\/a/\/b/ { print $1 }
awk: cmd. line:1: ^ syntax error
Leaving the prompt in a goofy state until the user hits a key.
Escaping the literal / in the parameter expansion (using "/^${1//\//\\/}/")
results in:
/^chartab/
allowing the completion to work correctly.
This formulation also works under bash.
Signed-off-by: John Szakmeister <john@szakmeister.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reported-by: "Mladen B." <mladen074@gmail.com>
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The __git_remotes() helper function lists the remotes from the config
file by processing the output of a 'git config' query. A simple 'git
remote' produces the exact same output, so run that instead.
Remotes under '$GIT_DIR/remotes' are still listed by running 'ls -1',
because 'git remote' unfortunately ignores them.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git log --invert-grep --grep=WIP" will show only commits that do
not have the string "WIP" in their messages.
* cj/log-invert-grep:
log: teach --invert-grep option
Using the exit status of the last command in the prompt, e.g.
PS1='$(__git_ps1) $? ', did not work well because the helper
function stomped on the exit status.
* tf/prompt-preserve-exit-status:
git-prompt: preserve value of $? in all cases
* rh/hide-prompt-in-ignored-directory:
git-prompt.sh: allow to hide prompt for ignored pwd
git-prompt.sh: if pc mode, immediately set PS1 to a plain prompt
"git log --grep=<string>" shows only commits with messages that
match the given string, but sometimes it is useful to be able to
show only commits that do *not* have certain messages (e.g. "show
me ones that are not FIXUP commits").
Originally, we had the invert-grep flag in grep_opt, but because
"git grep --invert-grep" does not make sense except in conjunction
with "--files-with-matches", which is already covered by
"--files-without-matches", it was moved it to revisions structure.
To have the flag there expresses the function to the feature better.
When the newly inserted two tests run, the history would have commits
with messages "initial", "second", "third", "fourth", "fifth", "sixth"
and "Second", committed in this order. The commits that does not match
either "th" or "Sec" is "second" and "initial". For the case insensitive
case only "initial" matches.
Signed-off-by: Christoph Junghans <ottxor@gentoo.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Using the exit status of the last command in the prompt, e.g.
PS1='$(__git_ps1) $? ', did not work well because the helper
function stomped on the exit status.
* tf/prompt-preserve-exit-status:
git-prompt: preserve value of $? inside shell prompt
The top-of-the-file instruction for completion scripts (in contrib/)
did not name the files correctly.
* pd/completion-filenames-fix:
Update documentation occurrences of filename .sh
This option was added in 58794775 (rebase: implement
--[no-]autostash and rebase.autostash, 2013-05-12).
Completion of "--autosquash" has been there, but this was not;
addition of this would require people completing "--autosquash" to
type a bit more than before.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Optionally set __git_ps1 to display nothing when present working
directory is ignored, triggered by the new environment variable
GIT_PS1_HIDE_IF_PWD_IGNORED. This environment variable may be
overridden on any repository by setting bash.hideIfPwdIgnored to
"false". In the absence of GIT_PS1_HIDE_IF_PWD_IGNORED this change
has no effect.
Many people manage e.g. dotfiles in their home directory with git.
This causes the prompt generated by __git_ps1 to refer to that "top
level" repo while working in any descendant directory. That can be
distracting, so this patch helps one shut off that noise.
Signed-off-by: Jess Austin <jess.austin@gmail.com>
Signed-off-by: Richard Hansen <rhansen@bbn.com>
Reviewed-by: Richard Hansen <rhansen@bbn.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
At the beginning of __git_ps1, right after determining that the
function is running in pc mode, set PS1 to a plain (undecorated)
prompt. This makes it possible to simply return early without having
to set PS1 if the prompt should not be decorated.
Signed-off-by: Richard Hansen <rhansen@bbn.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git-prompt" (in contrib/) used a variable from the global scope,
possibly contaminating end-user's namespace.
* jg/prompt-localize-temporary:
git-prompt.sh: make $f local to __git_eread()
If you have a prompt which displays the command exit status,
__git_ps1 without this change corrupts it, although it has
the correct value in the parent shell:
~/src/git (master) 0 $ set | grep ^PS1
PS1='\w$(__git_ps1) $? \$ '
~/src/git (master) 0 $ false
~/src/git (master) 0 $ echo $?
1
~/src/git (master) 0 $
There is a slightly ugly workaround:
~/src/git (master) 0 $ set | grep ^PS1
PS1='\w$(x=$?; __git_ps1; exit $x) $? \$ '
~/src/git (master) 0 $ false
~/src/git (master) 1 $
This change makes the workaround unnecessary.
Signed-off-by: Tony Finch <dot@dotat.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation in the completion scripts for Bash and Zsh state the wrong filenames.
Signed-off-by: Peter van der Does <peter@avirtualhome.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This function uses (non-local) $f to store the value of its first parameter.
This can interfere with the user's environment.
Signed-off-by: Justin Guenther <jguenther@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add completion for git-tag options including
all options that are currently shown in "git tag -h".
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The thread at http://thread.gmane.org/gmane.comp.version-control.git/257392
details problems when applying patches with "git am" in a repository with
CRLF line endings. In the example in the thread, the repository originated
from "git-svn" so it is not possible to use core.eol and friends on it.
Right now, the best option is to use "git am --keep-cr". However, when
a patch create new files, the patch application process will reject the
new file because it finds a "/dev/null\r" string instead of "/dev/null".
The problem is that SMTP transport is CRLF-unsafe. Sending a patch by
email is the same as passing it through "dos2unix | unix2dos". The newly
introduced CRLFs are normally transparent because git-am strips them. The
keepcr=true setting preserves them, but it is mostly working by chance
and it would be very problematic to have a "git am" workflow in a
repository with mixed LF and CRLF line endings.
The MIME solution to this is the quoted-printable transfer enconding.
This is not something that we want to enable by default, since it makes
received emails horrible to look at. However, it is a very good match
for projects that store CRLF line endings in the repository.
The only disadvantage of quoted-printable is that quoted-printable
patches fail to apply if the maintainer uses "git am --keep-cr". This
is because the decoded patch will have two carriage returns at the end
of the line. Therefore, add support for base64 transfer encoding too,
which makes received emails downright impossible to look at outside
a MUA, but really just works.
The patch covers all bases, including users that still live in the late
80s, by also providing a 7bit content transfer encoding that refuses
to send emails with non-ASCII character in them. And finally, "8bit"
will add a Content-Transfer-Encoding header but otherwise do nothing.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some internal error messages leaked out of the bash completion when
typing "git cmd <TAB>" and the machinery tried to complete
refnames.
* js/completion-hide-not-a-repo:
completion: silence "fatal: Not a git repository" error
Beyond Compare version 4 works the same way as version 3, so rename
the existing "bc3" adaptor to just "bc", while keeping "bc3" as a
backward compatible wrapper.
Noticed-by: Olivier Croquette <ocroquette@free.fr>
Helped-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is possible that a user is trying to run a git command and fail
to realize that they are not in a git repository or working tree.
When trying to complete an operation, __git_refs would fall to a
degenerate case and attempt to use "git for-each-ref", which would
emit the error.
Hide this error message coming from "git for-each-ref".
Signed-off-by: John Szakmeister <john@szakmeister.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We have had "git -C $there" to first go to a different directory
and run a Git command without changing the arguments for quite some
time. Use it instead of (cd $there && git ...) in the completion
script.
This allows us to lose the work-around for misfeatures of modern
interactive-minded shells that make "cd" unusable in scripts (e.g.
end users' $CDPATH taking us to unexpected places in any POSIX
shell, and chpwd functions spewing unwanted output in zsh).
Based on Øystein Walle's idea, which was raised during the
discussion on the solution by Brandon Turner for a problem zsh users
had with RVM which mucks with chpwd_functions in users' environments
(https://github.com/wayneeseguin/rvm/issues/3076).
As $root variable, which is used to direct where to chdir to, is set
to "." based on if $2 to __git_index_files is set (not if it is empty),
the only caller of the function is fixed not to pass the optional $2
when it does not want us to switch to a different directory. Otherwise
we would end up doing "git -C '' command...", which would not work.
Maybe we would want "git -C '' command..." to mean "do not chdir
anywhere", but that is a spearate topic.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The prompt script checked $GIT_DIR/ref/stash file to see if there
is a stash, which was a no-no.
* jk/prompt-stash-could-be-packed:
git-prompt: do not look for refs/stash in $GIT_DIR
Since dd0b72c (bash prompt: use bash builtins to check stash
state, 2011-04-01), git-prompt checks whether we have a
stash by looking for $GIT_DIR/refs/stash. Generally external
programs should never do this, because they would miss
packed-refs.
That commit claims that packed-refs does not pack
refs/stash, but that is not quite true. It does pack the
ref, but due to a bug, fails to prune the ref. When we fix
that bug, we would want to be doing the right thing here.
Signed-off-by: Jeff King <peff@peff.net>
Reviewed-by: Michael Haggerty <mhagger@alum.mit.edu>
Reviewed-by: Ronnie Sahlberg <sahlberg@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since the argument to `--recurse-submodules` is mandatory, it does not
need to be stuck to the option with `=`.
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'!f() { ... }; f' and "!sh -c '....' -" are recommended patterns for
declaring more complex aliases (see git wiki [1]). This commit teaches
the completion to handle them.
When determining which completion to use for an alias, an opening brace
or single quote is now skipped, and the search for a git command is
continued. For example, the aliases '!f() { git commit ... }' or "!sh
-c 'git commit ...'" now trigger commit completion. Previously, the
search stopped on the opening brace or quote, and the completion tried
it to determine how to complete, which obviously was useless.
The null command ':' is now skipped, so that it can be used as
a workaround to declare the desired completion style.
For example, the aliases
!f() { : git commit ; if ... } f
!sh -c ': git commit; if ...' -
now trigger commit completion.
Shell function declarations now work with or without space before
the parens, i.e. '!f() ...' and '!f () ...' both work.
[1] https://git.wiki.kernel.org/index.php/Aliases
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The options added to __git_merge_options are those that git-pull passes
to git-merge, since that variable is used by both commands.
Those added directly in _git_merge() are specific to git-merge and
are not passed thru from git-pull.
Reported-by: Haralan Dobrev <hkdobrev@gmail.com>
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This should avoid future confusion after a subsequent patch has added
some options to __git_merge_options and some directly in _git_merge().
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Not all shells subject the prompt string to parameter expansion. Test
whether the shell will expand the value of PS1, and use the result to
control whether raw ref names are included directly in PS1.
This fixes a regression introduced in commit 8976500 ("git-prompt.sh:
don't put unsanitized branch names in $PS1"): zsh does not expand PS1
by default, but that commit assumed it did. The bug resulted in
prompts containing the literal string '${__git_ps1_branch_name}'
instead of the actual branch name.
Reported-by: Caleb Thompson <caleb@calebthompson.io>
Signed-off-by: Richard Hansen <rhansen@bbn.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Otherwise it might collide with a function of the same name in the
user's environment.
Suggested-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Both bash and zsh subject the value of PS1 to parameter expansion,
command substitution, and arithmetic expansion. Rather than include
the raw, unescaped branch name in PS1 when running in two- or
three-argument mode, construct PS1 to reference a variable that holds
the branch name. Because the shells do not recursively expand, this
avoids arbitrary code execution by specially-crafted branch names such
as '$(IFS=_;cmd=sudo_rm_-rf_/;$cmd)'.
Signed-off-by: Richard Hansen <rhansen@bbn.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
zsh seems to have a bug while redirecting the stderr of the 'read'
command:
% read foo 2>/dev/null <foo
zsh: no such file or directory: foo
Which causes errors to be displayed when certain files are missing.
Let's add a convenience function to manually check if the file is
readable before calling "read".
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some commands need the first word to determine the actual action that is
being executed, however, the command is wrong when we use an alias, for
example 'alias.p=push', if we try to complete 'git p origin ', the
result would be wrong because __git_complete_remote_or_refspec() doesn't
know where it came from.
So let's override words[1], so the alias 'p' is override by the actual
command, 'push'.
Reported-by: Aymeric Beaumet <aymeric.beaumet@gmail.com>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The bash/zsh completion code did not know about format.coverLetter
among many format.* configuration variables.
* rr/completion-format-coverletter:
completion: complete format.coverLetter
When attempting to complete
$ git config remote.push<TAB>
'pushdefault' doesn't come up. This is because "$cur" is matched with
"remote.*" and a list of remotes are completed. Add 'pushdefault' as a
candidate for completion too, using __gitcomp_nl_append ().
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When attempting to complete
$ git config branch.auto<TAB>
'autosetupmerge' and 'autosetuprebase' don't come up. This is because
"$cur" is matched with "branch.*" and a list of branches are
completed. Add 'autosetupmerge', 'autosetuprebase' as candidates for
completion too, using __gitcomp_nl_append ().
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are situations where multiple classes of completions possible. For
example
branch.<TAB>
should try to complete
branch.master.
branch.autosetupmerge
branch.autosetuprebase
The first candidate has the suffix ".", and the second/ third candidates
have the suffix " ". To facilitate completions of this kind, create a
variation of __gitcomp_nl () that appends to the existing list of
completion candidates, COMPREPLY.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If zsh completion is being read from a location that is different from
system-wide default, it is likely that the user is trying to use a
custom version, perhaps closer to the bleeding edge, installed in her
own directory. We will more likely to find the matching bash completion
script in the same directory than in those system default places.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jn/scripts-updates:
remove #!interpreter line from shell libraries
test: replace shebangs with descriptions in shell libraries
test: make FILEMODE a lazy prereq
contrib: remove git-p4import
mark contributed hooks executable
mark perl test scripts executable
mark Windows build scripts executable
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>
This has been deprecated since commit 87194d2 (Deprecate peek-remote,
2007-11-24), included in version 1.5.4.
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git lost-found" has been deprecated since commit fc8b5f0 (Deprecate
git-lost-found, 2007-11-08), included in version 1.5.4.
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git tar-tree" has been a thin wrapper around "git archive" since commit
fd88d9c (Remove upload-tar and make git-tar-tree a thin wrapper to
git-archive, 2006-09-24), which also made it print a message indicating
that git-tar-tree is deprecated.
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The release notes for Git 1.5.4 say that "git repo-config" will be
removed in the next feature release. Since Git 2.0 is nearly here,
remove it.
Signed-off-by: John Keeping <john@keeping.me.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The '+=' operator is not supported by old Bash versions (3.0) we still
care about.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When working with multiple remotes, it is common to switch the upstream
from a remote to another. Doing so, the prompt may not be the expected
one. Providing an option to display tracking information sounds useful.
Add a "name" option to GIT_PS1_SHOWUPSTREAM which will show the upstream
abbrev name. This option is ignored if "verbose" is false.
Signed-off-by: Julien Carsique <julien.carsique@gmail.com>
Improved-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
DiffMerge is a non-free (but gratis) tool that supports OS X, Windows and Linux.
See http://www.sourcegear.com/diffmerge/
DiffMerge includes a script `/usr/bin/diffmerge` that can be used to launch the
graphical compare tool.
This change adds mergetool support for DiffMerge and adds 'diffmerge' as an
option to the mergetool help.
Signed-off-by: Stefan Saasen <ssaasen@atlassian.com>
Acked-by: David Aguilar <davvid@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Similar to Bash's default filename completion, our git-aware filename
completion stops at directory boundaries, i.e. it doesn't offer the
full 'path/to/file' at first, but only 'path/'. To achieve that the
completion script runs 'git ls-files' with specific command line
options to get the list of relevant paths under the current directory,
and then processes each path to strip all but the base directory or
filename (see __git_index_files()).
To offer only modified and untracked files for 'git add' the
completion script runs 'git ls-files --exclude-standard --others
--modified'. This command lists all non-ignored files in untracked
directories, which leads to a noticeable delay caused by the
processing mentioned above if there are a lot of such files
(__git_index_files() specifies '--exclude-standard' internally):
$ mkdir untracked-dir
$ for i in {1..10000} ; do >untracked-dir/$i ; done
$ time __git_index_files "--others --modified"
untracked-dir
real 0m0.537s
user 0m0.452s
sys 0m0.160s
Eliminate this delay by additionally passing the '--directory
--no-empty-directory' options to 'git ls-files' to show only the
directory name of non-empty untracked directories instead their whole
content:
$ time __git_index_files "--others --modified --directory --no-empty-directory"
untracked-dir
real 0m0.029s
user 0m0.020s
sys 0m0.004s
Filename completion for 'git clean' suffers from the same delay, as it
offers untracked files, too. The fix could be the same, but since it
actually makes sense to 'git clean' empty directories, in this case we
only pass the '--directory' option to 'git ls-files'.
Reported-by: Isaac Levy <ilevy@google.com>
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Old Bash (3.0) which is distributed with RHEL 4.X and other ancient
platforms that are still in wide use, do not have a printf that
supports -v. Neither does Zsh (which is already handled in the code).
As suggested by Junio, let's test whether printf supports the -v
option and store the result. Then later, we can use it to
determine whether 'printf -v' can be used, or whether printf
must be called in a subshell.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The syntax for retrieving the number of elements in an array is:
${#name[@]}
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Cygwin port added a "not quite correct but a lot faster and good
enough for many lstat() calls that are only used to see if the
working tree entity matches the index entry" lstat() emulation some
time ago, and it started biting us in places. This removes it and
uses the standard lstat() that comes with Cygwin.
Recent topic that uses lstat on packed-refs file is broken when
this cheating lstat is used, and this is a simplest fix that is
also the cleanest direction to go in the long run.
* rj/cygwin-clarify-use-of-cheating-lstat:
cygwin: Remove the Win32 l/stat() implementation
50c5885e (git-completion.bash: replace zsh notation that breaks bash
3.X, 2013-01-18) fixed a zsh-ism introduced earlier to append to an
array, which older versions of bash (3.0) did not grok. This was
again broken by 734b2f05 (completion: synchronize zsh wrapper,
2013-05-08).
Cherry-pick the fix again to let those with older bash use the
completion script.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A new command to allow scripts to query the mailmap information.
* es/check-mailmap:
t4203: test check-mailmap command invocation
builtin: add git-check-mailmap command
Commit adbc0b6b ("cygwin: Use native Win32 API for stat", 30-09-2008)
added a Win32 specific implementation of the stat functions. In order
to handle absolute paths, cygwin mount points and symbolic links, this
implementation may fall back on the standard cygwin l/stat() functions.
Also, the choice of cygwin or Win32 functions is made lazily (by the
first call(s) to l/stat) based on the state of some config variables.
Unfortunately, this "schizophrenic stat" implementation has been the
source of many problems ever since. For example, see commits 7faee6b8,
79748439, 452993c2, 085479e7, b8a97333, 924aaf3e, 05bab3ea and 0117c2f0.
In order to avoid further problems, such as the issue raised by the new
reference handling API, remove the Win32 l/stat() implementation.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce command check-mailmap, similar to check-attr and check-ignore,
which allows direct testing of .mailmap configuration.
As plumbing accessible to scripts and other porcelain, check-mailmap
publishes the stable, well-tested .mailmap functionality employed by
built-in Git commands. Consequently, script authors need not
re-implement .mailmap functionality manually, thus avoiding potential
quirks and behavioral differences.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Code clean-up for in-prompt status script (in contrib/).
* ed/color-prompt:
git-prompt.sh: add missing information in comments
git-prompt.sh: do not print duplicate clean color code
t9903: remove redundant tests
git-prompt.sh: refactor colored prompt code
t9903: add tests for git-prompt pcmode
git-completion.bash's parsing of the command name relies on everything
preceding it starting with '-' unless it is the "-c" option. This
allows users to use the stuck form of "--work-tree=<path>" and
"--namespace=<path>" but not the unstuck forms "--work-tree <path>" and
"--namespace <path>". Fix this.
Similarly, the completion only handles the stuck form "--git-dir=<path>"
and not "--git-dir <path>", so fix this as well.
Signed-off-by: John Keeping <john@keeping.me.uk>
Acked-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mention that the command below is needed for prompt
in ZSH with PS1:
setopt PROMPT_SUBST
Rephrase some parts that mention only the "current branch name"
being displayed in the prompt. Replace it by stating that
the "repository status" is displayed.
Make it clear that colored prompt is only available
in PROMPT_COMMAND/precmd mode.
With-suggestions-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Eduardo R. D'Avila <erdavila@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Do not print a duplicate clean color code when there
is no other indicators other than the current branch
in colored prompt.
Acked-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Eduardo R. D'Avila <erdavila@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
__git_ps1_colorize_gitstring() sets color codes and
builds the prompt gitstring. It has duplicated code
to handle color codes for bash and zsh shells.
__git_ps1() also has duplicated logic to build the
prompt gitstring.
Remove duplication of logic to build gitstring in
__git_ps1_colorize_gitstring() and __git_ps1().
Leave in __git_ps1_colorize_gitstring() only logic
to set color codes.
Signed-off-by: Eduardo R. D'Avila <erdavila@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
__git_ps1() is usually added to the prompt inside a command
substitution, imposing the overhead of fork()ing a subshell. Using
__git_ps1() for $PROMPT_COMMAND is slightly faster, because it avoids
that command substitution.
Mention this in the comments about setting up the git prompt.
The whole series speeds up the bash prompt on Windows/MSysGit
considerably. Here are some timing results in three scenarios, each
repeated 10 times:
At the top of the work tree, before:
$ time for i in {0..9} ; do prompt="$(__git_ps1)" ; done
real 0m1.716s
user 0m0.301s
sys 0m0.772s
After:
real 0m0.687s
user 0m0.075s
sys 0m0.396s
After, from $PROMPT_COMMAND:
$ time for i in {0..9} ; do __git_ps1 '\h:\w' '$ ' ; done
real 0m0.546s
user 0m0.075s
sys 0m0.181s
At the top of the work tree, detached head, before:
real 0m2.574s
user 0m0.376s
sys 0m1.207s
After:
real 0m1.139s
user 0m0.151s
sys 0m0.500s
After, from $PROMPT_COMMAND:
real 0m1.030s
user 0m0.245s
sys 0m0.336s
In a subdirectory, during rebase, stash status indicator enabled,
before:
real 0m3.557s
user 0m0.495s
sys 0m1.767s
After:
real 0m0.717s
user 0m0.120s
sys 0m0.300s
After, from $PROMPT_COMMAND:
real 0m0.577s
user 0m0.047s
sys 0m0.258s
On Linux the speedup ratio is comparable to Windows, but overall it
was about an order of magnitude faster to begin with. The last case
from above, repeated 100 times, before:
$ time for i in {0..99} ; do prompt="$(__git_ps1)" ; done
real 0m2.806s
user 0m0.180s
sys 0m0.264s
After:
real 0m0.857s
user 0m0.020s
sys 0m0.028s
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Before setting $PS1, __git_ps1() uses a command substitution to
redirect the output from a printf into a variable. Spare the overhead
of fork()ing a subshell by using 'printf -v <var>' to directly assign
the output to that variable.
zsh's printf doesn't support the '-v <var>' option, so stick with the
command substitution when under zsh.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
When enabled, the bash prompt can indicate the presence of untracked
files with a '%' sign. __git_ps1() checks for untracked files by running the
'$(git ls-files --others --exclude-standard)' command substitution,
and displays the indicator when there is no output.
Avoid this command substitution by additionally passing
'--error-unmatch *', and checking the command's return value.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
When the environment variable $GIT_PS1_SHOWSTASHSTATE is set
__git_ps1() checks the presence of stashes by running 'git rev-parse
--verify refs/stash'. This command not only checks that the
'refs/stash' ref exists but also, well, verifies that it's a valid
ref.
However, we don't need to be that thorough for the bash prompt. We
can omit that verification and only check whether 'refs/stash' exists
or not. Since 'git pack-refs' never packs 'refs/stash', it's a matter
of checking the existence of a ref file. Perform this check using
only bash builtins to spare the overhead of fork()+exec()ing a git
process.
Also run 'git pack-refs --all' in the corresponding test to document
that the prompt script depends on 'git pack-refs' not packing
'refs/stash' and to catch possible breakages should this behavior ever
change.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
When the dirty work tree and index status indicator is enabled,
__git_ps1() checks for changes in the index by running 'git diff-index
--cached --quiet HEAD --' and looking at its exit code. However, that
makes sense only when HEAD points to a valid commit: on an unborn
branch the failure of said command would be caused by the invalid
HEAD, not by changes in the index. Therefore, __git_ps1() first
checks for a valid HEAD by running 'git rev-parse --quiet --verify
HEAD'.
Since the previous patch we implicitly check HEAD's validity by
running 'git rev-parse ... --short HEAD', making the dirty status
indicator's 'git rev-parse' check redundant. It's sufficient to check
for non-emptyness of the variable holding the abbreviated commit
object name, thereby sparing the overhead of fork()+exec()ing a git
process.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
When describing a detached HEAD according to the $GIT_PS1_DESCRIBE
environment variable fails, __git_ps1() now runs the '$(git rev-parse
--short HEAD)' command substitution to get the abbreviated detached
HEAD commit object name. This imposes the overhead of fork()ing a
subshell and fork()+exec()ing a git process.
Avoid this overhead by combining this command substitution with the
"main" 'git rev-parse' execution for getting the path to the .git
directory & co. This means that we'll look for the abbreviated commit
object name even when it's not necessary, because we're on a branch or
the detached HEAD can be described. It doesn't matter, however,
because once 'git rev-parse' is up and running to fulfill all those
other queries, the additional overhead of looking for the abbreviated
commit object name is not measurable because it's lost in the noise.
There is a caveat, however, when we are on an unborn branch, because
in that case HEAD doesn't point to a valid commit, hence the query for
the abbreviated commit object name fails. Therefore, '--short HEAD'
must be the last options to 'git rev-parse' in order to get all the
other necessary information for the prompt even on an unborn branch.
Furthermore, in that case, and in that case only, 'git rev-parse'
doesn't output the last line containing the abbreviated commit object
name, obviously, so we have to take care to only parse it if 'git
rev-parse' exited without any error.
Although there are tests already excercising __git_ps1() on unborn
branches, they all do so implicitly. Add a test that checks this
explicitly.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
There are a couple of '$(git rev-parse --<opt>)' command substitutions
in __git_ps1() and three of them are executed in the main code path:
- the first to get the path to the .git directory ('--git-dir'),
- the second to check whether we're inside the .git directory
('--is-inside-git-dir'),
- and the last, depending on the results of the second, either
* to check whether it's a bare repo ('--is-bare-repository'), or
* to check whether inside a work tree ('--is-inside-work-tree').
Naturally, this imposes the overhead of fork()ing three subshells and
fork()+exec()ing three git commands.
Combine these four 'git rev-parse' queries into a single one and use
bash parameter expansions to parse the combined output, i.e. to
separate the path to the .git directory from the true/false of
'--is-inside-git-dir', etc. This way we can eliminate two of the
three subshells and git commands.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
