* sg/completion:
bash: support pretty format aliases
bash: support more 'git notes' subcommands and their options
bash: not all 'git bisect' subcommands make sense when not bisecting
bash: offer refs for 'git bisect start'
Commit 06f44c3 (completion: make compatible with zsh) broke bash
compatibility with 'set -u': a warning was generated when checking
$ZSH_VERSION. The solution is to supply a default value, using
${ZSH_VERSION-}. Thanks to SZEDER Gábor for the fix.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Ever since commit 70c9ac2 (DWIM: "git checkout frotz" to "git checkout
-b frotz origin/frotz"), git checkout has supported a DWIM mode where
it creates a local tracking branch for a remote branch if just the name
of the remote branch is specified on the command-line and only one remote
has a branch with that name. Teach the bash completion script to understand
this DWIM mode and provide such remote-tracking branch names as possible
completions.
Signed-off-by: Kevin Ballard <kevin@sb.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Users can have their own pretty format aliases since 8028184 (pretty:
add aliases for pretty formats, 2010-05-02), so let's offer those
after '--pretty=' and '--format=' for 'log' and 'show', too.
Similar to the completion of aliases, this will invoke 'git config'
each time pretty aliases needs to be completed, so changes in pretty.*
configuration will be reflected immediately.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current completion function for 'git notes' only supported the
'edit' and 'show' subcommands and none of their options. This patch
adds support for all missing subcommands, options, and their arguments
(files or refs), if any.
The code responsible for completing subcommand looks different
compared to the completion functions of other git commands with
subcommands. This is because of the '--ref <notes-ref>' option which
comes before the subcommand (i.e. git notes --ref <notes-ref> add).
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
... but only 'start' and 'replay'. The other commands will either
error out or offer to start bisecting for the user.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The completion script only offered path completion after 'git bisect
start', although bad and good refs could also be specified before the
doubledash.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Modify git-completion.bash so that it also works with zsh when using
bashcompinit. In particular:
declare -F
Zsh doesn't have the same 'declare -F' as bash, but 'declare -f'
is the same, and it works just as well for our purposes.
${var:2}
Zsh does not implement ${var:2} to skip the first 2 characters, but
${var#??} works in both shells to replace the first 2 characters
with nothing. Thanks to Jonathan Nieder for the suggestion.
for (( n=1; "$n" ... ))
Zsh does not allow "$var" in arithmetic loops. Instead, pre-compute
the endpoint and use the variables without $'s or quotes.
shopt
Zsh uses 'setopt', which has a different syntax than 'shopt'. Since
'shopt' is used infrequently in git-completion, we provide
a bare-bones emulation.
emulate -L bash
KSH_TYPESET
Zsh offers bash emulation, which turns on a set of features to
closely resemble bash. In particular, this enables SH_WORDSPLIT,
which splits scalar variables on word boundaries in 'for' loops.
We also need to set KSH_TYPESET, to fix "local var=$(echo foo bar)"
issues.
The last set of options are turned on only in _git and _gitk. Some of
the sub-functions may not work correctly if called directly.
Signed-off-by: Mark Lodato <lodatom@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a notification in the command prompt specifying whether (and optionally how
far) your branch has diverged from its upstream. This is especially helpful in
small teams that very frequently (forget to) push to each other.
Support git-svn upstream detection as a special case, as migrators from
centralised version control systems are especially likely to forget to push.
Support for other types of upstream than SVN should be easy to add if anyone is
so inclined.
Signed-off-by: Andrew Sayers <andrew-git@pileofstuff.org>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Define several variables in __git_ps1 to avoid errors under "set -u" semantics.
__git_ps1 seems to have been missed when the rest of the file was fixed in
25a31f8.
Signed-off-by: Andrew Sayers <andrew-git@pileofstuff.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Update git-completion.bash with new --orphan option to 'git checkout'.
Signed-off-by: Erick Mattos <erick.mattos@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We already complete HEAD, of course, and might as well complete the other
common refs mentioned in the rev-parse man page: FETCH_HEAD, ORIG_HEAD, and
MERGE_HEAD.
Signed-off-by: Ian Ward Comfort <icomfort@stanford.edu>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitk aliases either start with "!gitk", or look something like "!sh -c
FOO=bar gitk", IOW they contain the "gitk" word. With this patch the
completion script will recognize these cases and will offer gitk's
options.
Just like the earlier change improving on aliased command recognition,
this change can also be fooled easily by some complex aliases, but
users of such aliases could remedy it with custom completion
functions.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Shell command aliases can get rather complex, and the completion
script can not always determine correctly the git command invoked by
such an alias. For such cases users might want to provide custom
completion scripts the same way like for their custom commands made
possible by the previous patch.
The current completion script does not allow this, because if it
encounters an alias, then it will unconditionally perform completion
for the aliased git command (in case it can determine the aliased git
command, of course). With this patch the completion script will first
search for a completion function for the command given on the command
line, be it a git command, a custom git command of the user, or an
alias, and invoke that function to perform the completion. This has
no effect on git commands, because they can not be aliased anyway. If
it is an alias and there is a completion function for that alias (e.g.
_git_foo() for the alias 'foo'), then it will be invoked to perform
completion, allowing users to provide custom completion functions for
aliases. If such a completion function can not be found, only then
will the completion script check whether the command given on the
command line is an alias or not, and proceed as usual (i.e. find out
the aliased git command and provide completion for it).
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The bash completion script already provides support to complete
aliases, options and refs for aliases (if the alias can be traced back
to a supported git command by __git_aliased_command()), and the user's
custom git commands, but it does not support the options of the user's
custom git commands (of course; how could it know about the options of
a custom git command?). Users of such custom git commands could
extend git's bash completion script by writing functions to support
their commands, but they might have issues with it: they might not
have the rights to modify a system-wide git completion script, and
they will need to track and merge upstream changes in the future.
This patch addresses this by providing means for users to supply
custom completion scriplets for their custom git commands without
modifying the main git bash completion script.
Instead of having a huge hard-coded list of command-completion
function pairs (in _git()), the completion script will figure out
which completion function to call based on the command's name. That
is, when completing the options of 'git foo', the main completion
script will check whether the function '_git_foo' is declared, and if
declared, it will invoke that function to perform the completion. If
such a function is not declared, it will fall back to complete file
names. So, users will only need to provide this '_git_foo' completion
function in a separate file, source that file, and it will be used the
next time they press TAB after 'git foo '.
There are two git commands (stage and whatchanged), for which the
completion functions of other commands were used, therefore they
got their own completion function.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To support completion for aliases, the completion script tries to
figure out which git command is invoked by an alias. Its
implementation in __git_aliased_command() is rather straightforward:
it returns the first word from the alias. For simple aliases starting
with the git command (e.g. alias.last = cat-file commit HEAD) this
gives the right results. Unfortunately, it does not work with shell
command aliases, which can get rather complex, as illustrated by one
of Junio's aliases:
[alias]
lgm = "!sh -c 'GIT_NOTES_REF=refs/notes/amlog git log \"$@\" || :' -"
In this case the current implementation returns "!sh" as the aliased
git command, which is obviosly wrong.
The full parsing of a shell command alias like that in the completion
code is clearly unfeasible. However, we can easily improve on aliased
command recognition by eleminating stuff that is definitely not a git
command: shell commands (anything starting with '!'), command line
options (anything starting with '-'), environment variables (anything
with a '=' in it), and git itself. This way the above alias would be
handled correctly, and the completion script would correctly recognize
"log" as the aliased git command.
Of course, this solution is not perfect either, and could be fooled
easily. It's not hard to construct an alias, in which a word does not
match any of these filter patterns, but is still not a git command
(e.g. by setting an environment variable to a value which contains
spaces). It may even return false positives, when the output of a git
command is piped into an other git command, and the second gets the
command line options via $@, but options for the first one are
offered. However, the following patches will enable the user to
supply custom completion scripts for aliases, which can be used to
remedy these problematic cases.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
... and it will offer refs unless after -m or -F, because these two
options require a non-ref argument.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since commits a2d725b7 (Use an external program to implement fetching
with curl, 2009-08-05) and c9e388bb (Make the
"traditionally-supported" URLs a special case, 2009-09-03) remote
transport helpers like 'remote-ftp' and 'remote-curl' are offered by the
completion script as available subcommands. Not good, since they are
helpers, therefore should not be offered, so filter them out.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint-1.6.5:
Git 1.6.5.8
Fix mis-backport of t7002
bash completion: factor submodules into dirty state
reset: unbreak hard resets with GIT_WORK_TREE
Conflicts:
Documentation/git.txt
GIT-VERSION-GEN
RelNotes
In the implementation of GIT_PS1_SHOWDIRTYSTATE in 738a94a (bash:
offer to show (un)staged changes, 2009-02-03), I cut&pasted the
git-diff invocations from dirty-worktree checks elsewhere, carrying
along the --ignore-submodules option.
As pointed out by Kevin Ballard, this doesn't really make sense: to
the _user_, a changed submodule counts towards uncommitted changes.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Improve the readability of the bash prompt by adding a space between
the branch name and the status flags (dirty, stash, untracked).
While we are cleaning up this section of code, the two cases for
formatting the prompt are identical except for the format string,
so make them the same.
Suggested-by: Roman Fietze <roman.fietze@telemotive.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Support the new options --all, --prune, and --dry-run for
'git fetch'.
As the --multiple option was primarily introduced to enable
'git remote update' to be re-implemented in terms of 'git fetch'
(16679e37) and is not likely to be used much from the command
line, it does not seems worthwhile to complicate the code
(to support completion of multiple remotes) to handle it.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I just wanted to add the recently learnt '--reset-author' option, but
then noticed that there are many more options missing. This patch
adds support for all of 'git commit's options, except '--allow-empty',
because it is primarily there for foreign scm interfaces.
Furthermore, this patch also adds support for completing the arguments
of those options that take a non-filename argument: valid modes are
offered for '--cleanup' and '--untracked-files', while refs for
'--reuse-message' and '--reedit-message', because these two take a
commit as argument.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since git is not used in each and every interactive xterm, it
seems best to load completion support with cold caches and then
load each needed thing lazily. This has most of the speed
advantage of pre-generating everything at build time, without the
complication of figuring out at build time what commands will be
available at run time.
On this slow laptop, this decreases the time to load
git-completion.bash from about 500 ms to about 175 ms.
Suggested-by: Kirill Smelkov <kirr@mns.spb.ru>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Cc: Stephen Boyd <bebarino@gmail.com>
Cc: SZEDER Gábor <szeder@ira.uka.de>
Cc: Sverre Rabbelier <srabbelier@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add p4merge to the set of built-in diff/merge tools, and update
bash completion and documentation.
Signed-off-by: Scott Chacon <schacon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
So complete refs, files after the double-dash and some diff options that
make sense for difftool.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Complete all long options for 'git rebase' except --no-verify
(probably used very seldom) and the long options corresponding
to -v, -q, and -f.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Before the --, always attempt ref completion. This helps with
entering the <treeish> arguments to git-grep. As a bonus, you can
work around git-grep's current lack of --all by hitting M-*, ugly as
the resulting command line may be.
Strictly speaking, completing the regular expression argument (or
option argument) makes no sense. However, we cannot prevent _all_
completion (it will fall back to filenames), so we dispense with any
additional complication to detect whether the user still has to enter
a regular expression.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Aliases with newlines have been a problem since commit 56fc25f (Bash
completion support for remotes in .git/config., 2006-11-05). The chance
of the problem occurring has been slim at best, until commit 518ef8f
(completion: Replace config --list with --get-regexp, 2009-09-11)
removed the case statement introduced by commit 56fc25f. Before removing
the case statement, most aliases with newlines would work unless they
were specially crafted as follows
[alias]
foo = "log -1 --pretty='format:%s\nalias.error=broken'"
After removing the case statement, a more benign alias like
[alias]
whowhat = "log -1 --pretty='format:%an <%ae>\n%s'"
wont-complete = ...
would cause the completion to break badly.
For now, revert the removal of the case statement until someone comes up
with a better way to get keys from git-config.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After commit 511a3fc (wrap git's main usage string., 2009-09-12), the
bash completion for git commands includes COMMAND and [ARGS] when it
shouldn't. Fix this by grepping more strictly for a line with git
commands. It's doubtful whether git will ever have commands starting
with anything besides numbers and letters so this should be fine. At
least by being stricter we'll know when we break the completion earlier.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
