There is a convention that commands containing a double-dash
are implementation details and not to be used by mortals. We
should automatically remove them from the completion
suggestions as such.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I use "git diff" (the porcelain) really often, and am almost as often
annoyed that the completions do not know how to complete something simple
as --cached. Now they do.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This has been proposed for a few times without much reaction
from the list. Actually remove it to see who screams.
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
convert-objects was needed to convert from an old-style repository,
which hashed the compressed contents and used a different date format.
Such repositories are presumably no longer common and, if such
conversions are necessary, should be done by writing a frontend for
git-fast-import.
Linus, the original author, is OK with moving it to contrib.
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Lately I have been doing a lot of calls to `git tag -d` and also to
`git tag -v`. In both such cases being able to complete the names
of existing tags saves the fingers some typing effort. We now look
for the -d or -v option to git-tag in the bash completion support
and offer up existing tag names as possible choices for these.
When creating a new tag we now also offer bash completion support
for the second argument to git-tag (the object to be tagged) as this
can often be a specific existing branch name and is not necessarily
the current HEAD.
If the -f option is being used to recreate an existing tag we now
also offer completion support on the existing tag names for the
first argument of git-tag, helping to the user to reselect the
prior tag name that they are trying to replace.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Both --left-right and --cherry-pick are particularly long to type, so
help the user there.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The git-submodule command is new in 1.5.3 and contains a number
of useful subcommands for working on submodules. We usually try
to offer the subcommands of a git command in the bash completion,
so here they are for git-submodule.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I'm often finding that I need to run git-describe on very long
remote tracking branch names, to find out what tagged revision
the remote tracking branch is now at (or not at). Typing out
the ref names is painful, so bash completion on them is a very
useful feature.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
A number of commands have learned new tricks as part of git 1.5.3.
If these are long options (--foo) we tend to support them in the
bash completion, as it makes the user's task of using the option
slightly easier.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This is a new addition to 1.5.3; let's teach it to the
completion before the final release.
[sp: Added missing git-stash completion configuration]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Using `git push origin +foo` to forcefully overwrite the remote
branch named foo is a common idiom, especially since + is shorter
than the long option --force and can be specified on a per-branch
basis.
We now complete `git push origin +foo` just like we do the standard
`git push origin foo`. The leading + on a branch refspec does not
alter the completion.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Raimund Bauer just discovered that the default bash completion for
a local branch name in a git-push line is not the best choice when
the branch does not exist on the remote system.
In the past we have always completed the local name 'test' as
"test:test", indicating that the destination name is the same as
the local name. But this fails when "test" does not yet exist on
the remote system, as there is no "test" branch for it to match
the name against.
Fortunately git-push does the right thing when given just the
local branch, as it assumes you want to use the same name in the
destination repository. So we now offer "test" as the completion
in a git-push line, and let git-push assume that is also the remote
branch name.
We also still support the remote branch completion after the :,
but only if the user manually adds the colon before trying to get
a completion.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
A few new configuration options grew out of the woodwork during the
1.5.2 series. Most of these are pretty easy to support a completion
of, so we do so.
I wanted to also add completion support for the <driver> part of
merge.<driver>.name but to do that we have to look at all of the
.gitattributes files and guess what the unique set of <driver>
strings would be. Since this appears to be non-trivial I'm punting
on it at this time.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
(Somewhat) recently git-log learned about --reverse (to show commits
in the opposite order) and a looong time ago I think it learned
about --raw (to show the raw diff, rather than a unified diff).
These are both useful options, so we should make them easy for the
user to complete.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Recently the git-remote command grew an update subcommand, which
can be used to execute git-fetch across multiple repositories
in a single step. These can be configured with the 'remotes.*'
configuration options, so we can offer completion for any name that
matches and appears to be useful to git-remote update.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
1) Added a note about supporting the long options for most commands,
as we have been doing so for quite some time.
2) Include a notice that these routines are covered by the GPL,
as that may not be obvious, even though they are distributed
as part of the core Git distribution.
3) Added a short section on how to send patches to the routines,
and to whom they should get sent to. Currently that is me,
as I am the active maintainer.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This was just me being silly; I put the --not option into the
completion list twice. There's no duplicates shown in the shell
as the shell removes them before showing them to the user. But we
really don't need the duplicates in the source script either.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We've had completion for git-log for quite some time, but just
today I noticed we don't have it for the new builtin shortlog
that runs git-log internally. This is indeed a handy thing to
have completion for, especially when your branch names are of
the Very-Very-Long-and-Hard/To-Type/Variety/That-Some-Use.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The diff-* programs are meant to be plumbing for the diff frontend;
most end users aren't invoking these commands directly. Consequently
we should avoid showing them as possible completions.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
[sp: Modified Jonas' original patch to keep checkout-index
as a a valid completion.]
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Add a new configuration option clean.requireForce. If set, git-clean will
refuse to run, unless forced with the new -f option, or not acting due to -n.
Signed-off-by: Josh Triplett <josh@freedesktop.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The new git-fast-import command is not intended to be invoked
directly by an end user. So offering it as a possible completion
for a subcommand is not very useful.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Completing the 3 core subcommands to git-remote, along with the
names of remotes for 'show' and 'prune' (which take only existing
remotes) is handy.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Apparently `git-rebase -m` uses a metadata directory within .git
(.git/.dotest-merge) rather than .dotest used by git-am (and
git-rebase without the -m option). This caused the completion code
to not offer --continue, --skip or --abort when working within a
`git-rebase -m` session.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We now offer completion support for git-bisect's subcommands,
as well as ref name completion on the good/bad/reset subcommands.
This should make interacting with git-bisect slightly easier on
the fingers.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We've recently added --add as an argument to git-config, but I
missed putting it into the earlier round of git-config updates
within the bash completion.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Don't offer resolve as a possible subcommand completion. If you
read the top of the script, there is a big warning about how it
will go away soon in the near future. People should not be using it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I'm lazy. I don't want to type out --prune if bash can do it for
me with --<tab>.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Apparently nobody really makes use of git-diff-stages, as nobody
has complained that it is not supported by the git-diff frontend.
Since its likely this will go away in the future, we should not
offer it as a possible subcommand completion.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I just realized I did not support ref name completion for git-cherry.
This tool is just too useful to contributors who submit patches
upstream by email; completion support for it is very handy.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
format-patch/log/whatchanged all take --not and --all as options
to the internal revlist process. So these should be supported
as possible completions.
gitk takes anything rev-list/log/whatchanged takes, so we should
use complete_revlist to handle its options.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Because our use of -o nospace prevents bash from adding a trailing space
when a completion is unique and has been fully completed, we need to
perform this addition on our own. This (large) change converts all
existing uses of compgen to our wrapper __gitcomp which attempts to
handle this by tacking a trailing space onto the end of each offered
option.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In many cases we know a completion will be unique, but we've disabled
bash's automatic space addition (-o nospace) so we need to do it
ourselves when necessary.
This change adds additional support for new configuration options
added in 1.5.0, as well as some extended completion support for
the color.* family of options.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Most of these commands are not ones you want to invoke from the
command line on a frequent basis, or have been renamed in 1.5.0 to
more friendly versions, but the old names are being left behind to
support existing scripts in the wild.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Because we use the nospace option for our completion function for
the main 'git' wrapper bash won't automatically add a space after a
unique completion has been made by the user. This has been pointed
out in the past by Linus Torvalds as an undesired behavior. I agree.
We have to use the nospace option to ensure path completion for
a command such as `git show` works properly, but that breaks the
common case of getting the space for a unique completion. So now we
set IFS=$'\n' (linefeed) and add a trailing space to every possible
completion option. This causes bash to insert the space when the
completion is unique.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The new --interactive mode of git-add can be very useful, so users
will probably want to have completion for it.
Likewise the new git-add--interactive executable is actually a
plumbing command. Its invoked by `git add --interactive` and is
not intended to be invoked directly by the user. Therefore we
should hide it from the list of available Git commands.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that git-show is capable of displaying any file content from any
revision and is the approved Porcelain-ish level method of doing so,
cat-file should no longer be classified as a user-level utility by
the bash completion package.
I'm also classifying the new git-reflog command as plumbing for the
time being as there are no subcommands which are really useful to
the end-user. git-gc already invokes `git reflog expire --all`,
which makes it rather unnecessary for the user to invoke it directly.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The short options (-l, -f, -d) for git-branch are rather silly to
include in the completion generation as these options must be fully
typed out by the user and most users already know what the options
are anyway, so including them in the suggested completions does
not offer huge value. (The same goes for git-checkout and git-diff.)
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It is plausible for somebody to want to view the commit log in a
different encoding from i18n.commitencoding -- the project's
policy may be UTF-8 and the user may be using a commit message
hook to run iconv to conform to that policy (and either not have
i18n.commitencoding to default to UTF-8 or have it explicitly
set to UTF-8). Even then, Latin-1 may be more convenient for
the usual pager and the terminal the user uses.
The new variable i18n.logoutputencoding is used in preference to
i18n.commitencoding to decide what encoding to recode the log
output in when git-log and friends formats the commit log message.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that 'git show' accepts ref:path as an argument to specify a
tree or blob we should use the same completion logic as we support
for cat-file's object identifier.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
While adding colour to the branch command it was pointed out that a
config option like "branch.color" conflicts with the pre-existing
"branch.something" namespace used for specifying default merge urls and
branches. The suggested solution was to flip the order of the
components to "color.branch", which I did for colourising branch.
This patch does the same thing for
- git-log (color.diff)
- git-status (color.status)
- git-diff (color.diff)
- pager (color.pager)
I haven't removed the old config options; but they should probably be
deprecated and eventually removed to prevent future namespace
collisions. I've done this deprecation by changing the documentation
for the config file to match the new names; and adding the "color.XXX"
options to contrib/completion/git-completion.bash.
Unfortunately git-svn reads "diff.color" and "pager.color"; which I
don't like to change unilaterally.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Commit 35e65ecc broke completion of local refs, e.g. "git pull . fo<tab>"
no longer would complete to "foo". Instead it printed out an internal
git error ("fatal: Not a git repository: '.'").
The break occurred when I tried to improve performance by switching from
git-peek-remote to git-for-each-ref. Apparently git-peek-remote will
drop into directory "$1/.git" (where $1 is its first parameter) if it
is given a repository with a working directory. This allowed the bash
completion code to work properly even though it was not handing over
the true repository directory.
So now we do a stat in bash to see if we need to add "/.git" to the
path string before running any command with --git-dir.
I also tried to optimize away two "git rev-parse --git-dir" invocations
in common cases like "git log fo<tab>" as typically the user is in the
top level directory of their project and therefore the .git subdirectory
is in the current working directory. This should make a difference on
systems where fork+exec might take a little while.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since the user's git installation is not likely to grow a new command
or merge strategy in the lifespan of the current shell process we can
save time during completion operations by caching these lists during
sourcing of the completion support.
If the git executable is not available or we run into errors while
caching at load time then we defer these to runtime and generate
the list on the fly. This might happen if the user doesn't put git
into their PATH until after the completion script gets sourced.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Because git-merge and git-rebase both accept -s, --strategy or --strategy=
we should recognize all three formats in the bash completion functions and
issue back all merge strategies on demand.
I also moved the prior word testing to be before the current word testing,
as the current word cannot be completed with -- if the prior word was an
option which requires a parameter, such as -s or --strategy.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
