aboutsummaryrefslogtreecommitdiff
path: root/contrib
Commit message (Collapse)AuthorAge
* gitview: annotation supportAneesh Kumar K.V2007-04-20
| | | | | | | | | List files modifed as a part of the commit in the diff window Support annotation of the file listed in the diff window Support history browsing in the annotation window. Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git.el: Add a commit description to the reflog.Alexandre Julliard2007-04-19
| | | | | | | | Add a description of the commit to the reflog using the first line of the log message, the same way the git-commit script does it. Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Contribute a fairly paranoid update hookShawn O. Pearce2007-04-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | I'm using a variant of this update hook in a corporate environment where we perform some validations of the commits and tags that are being pushed. The model is a "central repository" type setup, where users are given access to push to specific branches within the shared central repository. In this particular installation we run a specially patched git-receive-pack in setuid mode via SSH, allowing all writes into the repository as the repository owner, but only if this hook blesses it. One of the major checks we perform with this hook is that the 'committer' line of a commit, or the 'tagger' line of a new annotated tag actually correlates to the UNIX user who is performing the push. Users can falsify these lines on their local repositories, but the central repository that management trusts will reject all such forgery attempts. Of course 'author' lines are still allowed to be any value, as sometimes changes do come from other individuals. Another nice feature of this hook is the access control lists for all repositories on the system can also be stored and tracked in a supporting Git repository, which can also be access controlled by itself. This allows full auditing of who-had-what-when-and-why, thanks to git-blame's data mining capabilities. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Merge branch 'maint'Junio C Hamano2007-04-05
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | * maint: Fix lseek(2) calls with args 2 and 3 swapped Honor -p<n> when applying git diffs Fix dependency of common-cmds.h Fix renaming branch without config file DESTDIR support for git/contrib/emacs gitweb: Fix bug in "blobdiff" view for split (e.g. file to symlink) patches Document --left-right option to rev-list. Revert "builtin-archive: use RUN_SETUP" rename contrib/hooks/post-receieve-email to contrib/hooks/post-receive-email. rerere: make sorting really stable. Fix t4200-rerere for white-space from "wc -l"
| * DESTDIR support for git/contrib/emacsVille Skyttä2007-04-05
| | | | | | | | | | | | | | make install DESTDIR=... support for git/contrib/emacs Signed-off-by: Ville Skyttä <scop@xemacs.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
| * rename contrib/hooks/post-receieve-email to contrib/hooks/post-receive-email.Gerrit Pape2007-04-04
| | | | | | | | | | | | | | | | | | | | $ git grep post-receieve-email $ git grep post-receive-email templates/hooks--post-receive:#. /usr/share/doc/git-core/contrib/hooks/post-receive-email $ Signed-off-by: Gerrit Pape <pape@smarden.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | git-blame.el: pick a set of random colors for each git-blame turnXavier Maillard2007-03-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I thought it would be cool to have different set of colors for each git-blame-mode. Function `git-blame-new-commit' does this for us picking when possible, a random colors based on the set we build on startup. When it fails, `git-blame-ancient-color' will be used. We also take care not to use the same color more than once (thank you David Kågedal, really). * Prevent (future possible) namespace clash by renaming `color-scale' into `git-blame-color-scale'. Definition has been changed to be more in the "lisp" way (thanks for help to #emacs). Also added a small description of what it does. * Added docstrings at some point and instructed defvar when a variable was candidate to customisation by users. * Added missing defvar to silent byte-compilers (git-blame-file, git-blame-current) * Do not require 'cl at startup * Added more informations on compatibility Signed-off-by: Xavier Maillard <zedek@gnu.org> Acked-by: David Kågedal <davidk@lysator.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | git-blame.el: separate git-blame-mode to ease maintenanceXavier Maillard2007-03-31
|/ | | | | | | | | | | | | | | git-blame-mode has been splitted into git-blame-mode-on and git-blame-mode-off; it now conditionnaly calls one of them depending of how we call it. Code is now easier to maintain and to understand. Fixed `git-reblame' function: interactive form was at the wrong place. String displayed on the mode line is now configurable through `git-blame-mode-line-string` (default to " blame"). Signed-off-by: Xavier Maillard <zedek@gnu.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* contrib/workdir: add a simple script to create a working directoryJulian Phillips2007-03-31
| | | | | | | | | | | | | | | | | | | Add a simple script to create a working directory that uses symlinks to point at an exisiting repository. This allows having different branches in different working directories but all from the same repository. Based on a description from Junio of how he creates multiple working directories[1]. With the following caveat: "This risks confusion for an uninitiated if you update a ref that is checked out in another working tree, but modulo that caveat it works reasonably well." [1] http://article.gmane.org/gmane.comp.version-control.git/41513/ Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Reimplement emailing part of hooks--update in contrib/hooks/post-receive-emailAndy Parkins2007-03-31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The update hook is no longer the correct place to generate emails; there is now the hooks/post-receive script which is run automatically after a ref has been updated. This patch is to make use of that new location, and to address some faults in the old update hook. The primary problem in the conversion was that in the update hook, the ref has not actually been changed, but is about to be. In the post-receive hook the ref has already been updated. That meant that where we previously had lines like: git rev-list --not --all would now give the wrong list because "--all" in the post-receive hook includes the ref that we are making the email for. This made it more difficult to show only the new revisions added by this update. The solution is not pretty; however it does work and doesn't need any changes to git-rev-list itself. It also fixes (more accurately: reduces the likelihood of) a nasty race when another update occurs while this script is running. The solution, in short, looks like this (see the source code for a longer explanation) git rev-parse --not --all | grep -v $(git rev-parse $refname) | git rev-list --pretty --stdin $oldrev..$newrev This uses git-rev-parse followed by grep to filter out the revision of the ref in question before it gets to rev-list and inhibits the output of itself. By using $(git rev-parse $revname) rather than $newrev as the filter, it also takes care of the situation where another update to the same ref has been made since $refname was $newrev. The second problem that is addressed is that of tags inhibiting the correct output of an update email. Consider this, with somebranch and sometag pointing at the same revision: git push origin somebranch git push origin sometag That would work fine; the push of the branch would generate an email containing all the new commits introduced by the update, then the push of the tag would generate the shortlog formatted tag email. Now consider: git push origin sometag git push origin somebranch When some branch comes to run its "--not --all" line, it will find sometag, and filter those commits from the email - leaving nothing. That meant that those commits would not show (in full) on any email. The fix is to not use "--all", and instead use "--branches" in the git-rev-parse command. Other changes * Lose the monstrous one-giant-script layout and put things in easy to digest functions. This makes it much easier to find the place you need to change if you wanted to customise the output. I've also tried to write more verbose comments for the same reason. The hook script is big, mainly because of all the different cases that it has to handle, so being easy to navigate is important. * All uses of "git-command" changed to "git command", to cope better if a user decided not to install all the hard links to git; * Cleaned up some of the English in the email * The fact that the receive hook makes the ref available also allows me to use Shawn Pearce's fantastic suggestion that an annotated tag can be parsed with git-for-each-ref. This removes the potentially non-portable use of "<<<" heredocs and the nasty messing around with "date" to convert numbers of seconds UTC to a real date * Deletions are now caught and notified (briefly) * To help with debugging, I've retained the command line mode from the update hook; but made it so that the output is not emailed, it's just printed to the screen. This could then be redirected if the user wanted * Removed the "Hello" from the beginning of the email - it's just noise, and no one seriously has their day made happier by "friendly" programs * The fact that it doesn't rely on repository state as an indicator any more means that it's far more stable in its output; hopefully the same arguments will always generate the same email - even if the repository changes in the future. This means you can easily recreate an email should you want to. * Included Jim Meyering's envelope sender option for the sendmail call * The hook is now so big that it was inappropriate to copy it to every repository by keeping it in the templates directory. Instead, I've put a comment saying to look in contrib/hooks, and given an example of calling the script from that template hook. The advantage of calling the script residing at some fixed location is that if a future package of git included a bug fixed version of the script, that would be picked up automatically, and the user would not have to notice and manually copy the new hook to every repository that uses it. Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git.el: Display some information about the HEAD commit.Alexandre Julliard2007-03-27
| | | | | | | | Use git-log --pretty=oneline to print a short description of the current HEAD (and merge heads if any) in the buffer header. Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* contrib/continuous: a continuous integration build managerShawn O. Pearce2007-03-19
| | | | | | | | | | | This is a simple but powerful continuous integration build system for Git. It works by receiving push events from repositories through the post-receive hook, aggregates them on a per-branch basis into a first-come-first-serve build queue, and lets a background build daemon perform builds one at a time. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git.el: Add support for commit hooks.Alexandre Julliard2007-03-19
| | | | | | | | Run the pre-commit and post-commit hooks at appropriate places, and display their output if any. Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Make gc a builtin.James Bowes2007-03-17
| | | | | Signed-off-by: James Bowes <jbowes@dangerouslyinc.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Merge branch 'maint'Junio C Hamano2007-03-10
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | * maint: git.el: Retrieve commit log information from .dotest directory. git.el: Avoid appending a signoff line that is already present. setup_git_directory_gently: fix off-by-one error user-manual: install user manual stylesheet with other web documents user-manual: fix rendering of history diagrams user-manual: fix missing colon in git-show example user-manual: fix inconsistent use of pull and merge user-manual: fix inconsistent example glossary: fix overoptimistic automatic linking of defined terms Documentation: s/seperator/separator/ Adjust reflog filemode in shared repository
| * git.el: Retrieve commit log information from .dotest directory.Alexandre Julliard2007-03-10
| | | | | | | | | | | | | | | | | | If a git-am or git-rebase is in progress, fill the commit log buffer from the commit information found in the various files in the .dotest directory. Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
| * git.el: Avoid appending a signoff line that is already present.Alexandre Julliard2007-03-10
| | | | | | | | | | | | | | | | Also avoid inserting an extra newline if other signoff lines are present. Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | contrib/emacs: Use non-interactive function to byte-compile filesXavier Maillard2007-03-05
| | | | | | | | | | | | | | | | | | | | Add git-blame as a candidate to the byte-compilation. batch-byte-compile is the prefered way to byte-compile files in batch mode. Use it instead of the interactive function. Signed-off-by: Xavier Maillard <zedek@gnu.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | Merge branch 'maint'Junio C Hamano2007-02-28
|\ \ | |/ | | | | | | | | | | | | | | | | | | * maint: Start preparing Release Notes for 1.5.0.3 Documentation: git-remote add [-t <branch>] [-m <branch>] [-f] name url Include config.mak in doc/Makefile git.el: Set the default commit coding system from the repository config. git-archimport: support empty summaries, put summary on a single line. http-push.c::lock_remote(): validate all remote refs. git-cvsexportcommit: don't cleanup .msg if not yet committed to cvs.
| * git.el: Set the default commit coding system from the repository config.Alexandre Julliard2007-02-28
| | | | | | | | | | | | | | | | | | | | | | If not otherwise specified, take the default coding system for commits from the 'i18n.commitencoding' repository configuration value. Also set the buffer-file-coding-system variable in the log buffer to make the selected coding system visible on the modeline. Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* | Merge branch 'maint'Junio C Hamano2007-02-27
|\ \ | |/ | | | | | | | | | | | | | | | | | | * maint: builtin-fmt-merge-msg: fix bugs in --file option index-pack: Loop over pread until data loading is complete. blameview: Fix the browse behavior in blameview Fix minor typos/grammar in user-manual.txt Correct ordering in git-cvsimport's option documentation git-show: Reject native ref Fix git-show man page formatting in the EXAMPLES section
| * blameview: Fix the browse behavior in blameviewAneesh Kumar2007-02-27
| | | | | | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* | Merge branch 'maint'Junio C Hamano2007-02-21
|\ \ | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * maint: Use gunzip -c over gzcat in import-tars example. git-gui: Don't crash in citool mode on initial commit. git-gui: Remove TODO list. git-gui: Include browser in our usage message. git-gui: Change summary of git-gui. git-gui: Display all authors of git-gui. git-gui: Use mixed path for docs on Cygwin. git-gui: Correct crash when saving options in blame mode. git-gui: Expose the browser as a subcommand. git-gui: Create new branches from a tag. git-gui: Prefer version file over git-describe. git-gui: Print version on the console. git-gui: More consistently display the application name. git-gui: Permit merging tags into the current branch. git-gui: Basic version check to ensure git 1.5.0 or later is used. git-gui: Refactor 'exec git subcmd' idiom.
| * Use gunzip -c over gzcat in import-tars example.Michael Loeffler2007-02-21
| | | | | | | | | | | | | | | | | | Not everyone has gzcat or bzcat installed on their system, but gunzip -c and bunzip2 -c perform the same task and are available if the user has installed gzip support or bzip2 support. Signed-off-by: Michael Loeffler <zvpunry@zvpunry.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* | Remove git-diff-stages.Junio C Hamano2007-02-12
| | | | | | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* | Remove git-resolve.Junio C Hamano2007-02-12
|/ | | | Signed-off-by: Junio C Hamano <junkio@cox.net>
* blameview: Move the commit info to a pane below the blame window.Aneesh Kumar K.V2007-02-12
| | | | | | | Also spawn the the new blameview in the background Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
* import-tars: brown paper bag fix for file mode.Michael Loeffler2007-02-12
| | | | | | | | There is a bug with this $git_mode variable which should be 0644 or 0755, but nothing else I think. Signed-off-by: Michael Loeffler <zvpunry@zvpunry.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* bash: Hide git-fast-import.Shawn O. Pearce2007-02-11
| | | | | | | | 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>
* remove mailmap.linuxNicolas Pitre2007-02-09
| | | | | | | | | | | This file is incomplete, unmaintained, and it doesn't belong in the GIT package anyway. A more complete version is already included in the Linux -mm tree and is about to make its way into mainline RSN. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-blame.el: Autoupdate while editingDavid Kågedal2007-02-09
| | | | | | | | | This adds the support for automatically updating the buffer while editing. A configuration variable git-blame-autoupdate controls whether this should be enabled or not. Signed-off-by: David Kågedal <davidk@lysator.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-blame.el: Doc fixes and cleanupDavid Kågedal2007-02-09
| | | | | Signed-off-by: David Kågedal <davidk@lysator.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-blame.el: blame unsaved changesDavid Kågedal2007-02-09
| | | | | | | | | | | Make git-blame use the current buffer contents for the blame, instead of the saved file. This makes the blame correct even if there are unsaved changes. Also added a git-reblame command. Signed-off-by: David Kågedal <davidk@lysator.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-blame.el: improve color handlingDavid Kågedal2007-02-09
| | | | | Signed-off-by: David Kågedal <davidk@lysator.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
* Handle uncommitted changes and cache descriptionsDavid Kågedal2007-02-09
| | | | | Signed-off-by: David Kågedal <davidk@lysator.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
* git-blame: Change installation instructionsJakub Narebski2007-02-09
| | | | | | | | | | | | | | | | 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>
* git-blame: Add Emacs Lisp file headers and GNU GPL boilerplateJakub Narebski2007-02-09
| | | | | | | | | | | | | | | | | | | | | 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>
* Merge branch 'master' of git://repo.or.cz/git/fastimportJunio C Hamano2007-02-08
|\ | | | | | | | | | | | | | | * '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.
| * tar archive frontend for fast-import.Shawn O. Pearce2007-02-08
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Remove contrib/colordiffJunio C Hamano2007-02-06
| | | | | | | | | | | | This has completely been superseded by built-in --color option. Signed-off-by: Junio C Hamano <junkio@cox.net>
* | bash: Complete git-remote subcommands.Shawn O. Pearce2007-02-05
| | | | | | | | | | | | | | | | | | 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>
* | bash: Support git-rebase -m continuation completion.Shawn O. Pearce2007-02-05
| | | | | | | | | | | | | | | | | | | | | | 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>
* | git-blame: an Emacs minor mode to view file with git-blame output.David Kågedal2007-02-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | Add hg-to-git conversion utility.Stelian Pop2007-02-05
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* | blameview: Support browsable functionality to blameview.Aneesh Kumar K.V2007-02-05
| | | | | | | | | | | | | | | | 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>
* | bash: Support git-bisect and its subcommands.Shawn O. Pearce2007-02-05
| | | | | | | | | | | | | | | | | | | | 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>
* | bash: Support --add completion to git-config.Shawn O. Pearce2007-02-05
| | | | | | | | | | | | | | | | | | 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>
* | bash: Hide git-resolve, its deprecated.Shawn O. Pearce2007-02-05
| | | | | | | | | | | | | | | | | | 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>
* | bash: Offer --prune completion for git-gc.Shawn O. Pearce2007-02-05
| | | | | | | | | | | | | | | | 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>
* | bash: Hide diff-stages from completion.Shawn O. Pearce2007-02-05
| | | | | | | | | | | | | | | | | | | | 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>