Change installation instructions to using either "(require 'git-blame)"
or appropriate autoload instruction in GNU Emacs init file, .emacs
This required adding "(provide 'git-blame)" at the end of git-blame.el
and adding [preliminary] docstring to `git-blame-mode' function for
consistency (to mark function as interactive in `autoload' we have to
provide docstring as DOCSTRING is third arg, and INTERACTIVE fourth,
and both are optional). `git-blame-mode' is marked to autoload.
While at it ensure that we add `git-blame-mode' to `minor-mode-alist'
only once (in a way that does not depend on `cl' package).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add Emacs Lisp file headers, according to "Coding Conventions" chapter
in Emacs Lisp Reference Manual and Elisp Area Convetions for
EmacsWiki:
http://www.emacswiki.org/cgi-bin/wiki/ElispAreaConventions
Those include: copyright notice, GNU GPL boilerplate, description and
instalation instructions as provided in email and in commit message
introducing git-blame.el, compatibility notes from another email by
David Kågedal about what to change to use it in GNU Emacs 20, and
"git-blame ends here" to detect if file was truncated. First line
includes setting file encoding via first line local variable values
(file variables).
Added comment to "(require 'cl)" to note why it is needed; "Coding
Conventions" advises to avoid require the `cl' package of Common Lisp
extensions at run time.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'master' of git://repo.or.cz/git/fastimport:
tar archive frontend for fast-import.
Correct spelling of fast-import in docs.
Correct some language in fast-import documentation.
Correct ^0 asciidoc syntax in fast-import docs.
This is an example fast-import frontend, in less than 100 lines
of Perl. It accepts one or more tar archives on the command line,
passes them through gzcat/bzcat/zcat if necessary, parses out the
individual file headers and feeds all contained data to fast-import.
No temporary files are involved.
Each tar is treated as one commit, with the commit timestamp coming
from the oldest file modification date found within the tar.
Each tar is also tagged with an annotated tag, using the basename
of the tar file as the name of the tag.
Currently symbolic links and hard links are not handled by the
importer. The file checksums are also not verified.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Added support for @all as revision range specifier to import all changes to a given depot path.
Also default to an import of #head if no revrange is specified.
Signed-off-by: Simon Hausmann <hausmann@kde.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>
Here's another version of git-blame.el that automatically tries to
create a sensible list of colors to use for both light and dark
backgrounds. Plus a few minor fixes.
To use:
1) Load into emacs: M-x load-file RET git-blame.el RET
2) Open a git-controlled file
3) Blame: M-x git-blame-mode
Signed-off-by: Junio C Hamano <junkio@cox.net>
hg-to-git.py is able to convert a Mercurial repository into a git one,
and preserves the branches in the process (unlike tailor)
hg-to-git.py can probably be greatly improved (it's a rather crude
combination of shell and python) but it does already work quite well for
me. Features:
- supports incremental conversion
(for keeping a git repo in sync with a hg one)
- supports hg branches
- converts hg tags
Signed-off-by: Stelian Pop <stelian@popies.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Double clicking on the row execs a new blameview with commit hash
as argument.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
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>
Use p4 files //depot/path/...@revision to determine the state of the project and create a "fake" git commit from it.
Signed-off-by: Simon Hausmann <hausmann@kde.org>
Try to find the last imported p4 change number from the git tags and try to pass the right parent for commits to git fast-import.
Signed-off-by: Simon Hausmann <hausmann@kde.org>
