It appears 'let' is not present in all shells.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It wasn't being checked properly before; those refs never existed.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Different repositories have different branches, some are are even
branches themselves.
Reported-by: Peter Niederlag <netservice@niekom.de>
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reported-by: Joakim Verona <joakim@verona.se>
Signed-off-by: Felipe Contreras <felipe.contreras@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>
git-contacts invokes git-blame once for each patch hunk it encounters.
No attempt is made to consolidate invocations for multiple hunks
referencing the same file at the same revision. This can become
expensive quickly.
Reduce the number of git-blame invocations by taking advantage of the
ability to specify multiple -L ranges for a single invocation.
Without this patch, on a randomly chosen range of commits:
% time git-contacts 25fba78d36be6297^..23c339c0f262aad2 >/dev/null
real 0m6.142s
user 0m5.429s
sys 0m0.356s
With this patch:
% time git-contacts 25fba78d36be6297^..23c339c0f262aad2 >/dev/null
real 0m2.285s
user 0m2.093s
sys 0m0.165s
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-contacts invokes git-blame immediately upon encountering a patch
hunk. No attempt is made to consolidate invocations for multiple hunks
referencing the same file at the same revision. This can become
expensive quickly.
Any effort to reduce the number of times git-blame is run will need to
to know in advance which line ranges to blame per file per revision.
Make this information available by collecting all sources as a distinct
step from invoking git-blame. A subsequent patch will utilize the
information to optimize git-blame invocations.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Rather than calling get_blame() with a zero-length hunk only to have it
rejected immediately, perform hunk-length validation earlier in order to
avoid calling get_blame() unnecessarily.
This is a preparatory step to simplify later patches which reduce the
number of git-blame invocations by collecting together all lines to
blame within a single file at a particular revision. By validating the
blame range early, the subsequent patch can more easily avoid adding
empty ranges at collection time.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Back when the core tutorial was written, `log` and `whatchanged`
were scripted Porcelains. In the "Inspecting Changes" section that
talks about the plumbing commands in the diff family, it made sense
to use `log` and `whatchanged` as good examples of the use of these
plumbing commands, and because even these scripted Porcelains were
novelty (there wasn't the new end-user tutorial written), it made
some sense to illustrate uses of the `git log` (and `git
whatchanged`) scripted Porcelain commands.
But we no longer have scripted `log` and `whatchanged` to serve as
examples, and this document is not where the end users learn what
`git log` command is about. Stop at briefly mentioning the
possibility of combining rev-list with diff-tree to build your own
log, and leave the end-user documentation of `log` to the new
tutorial and the user manual.
Also resurrect the last version of `git-log`, `git-whatchanged`, and
`git-show` to serve as examples to contrib/examples/ directory.
While at it, remove 'whatchanged' from a list of sample commands
that are affected by GIT_FLUSH environment variable. This is not
meant to be an exhaustive list but as a list of typical ones, and an
old command that is kept primarily for backward compatibility does
not belong to it.
Helped-by: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we have an old organization (v1.8.3), and want to upgrade to a newer
one (v1.8.4), the user would have to fetch the whole repository, instead
we can just move the repository, so the user would not notice any
difference.
Also, remove other clones, so in time they get set up as shared.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Reviewed-by: Antoine Pelisse <apelisse@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
6796d49 (remote-hg: use a shared repository store) introduced a bug by
making the shared repository '.git/hg', which is already used before
that patch, so clones that happened before that patch, fail after that
patch, because there's no shared Mercurial repo.
So, instead of simply checking if the directory exists, let's always try
to create an empty shared repository to ensure it's there. This works
because we don't need the initial clone, if the repository is shared,
pulling from the child updates the parent's storage; it's exactly the
same as cloning, so we can simplify the shared repo setup this way while
at the same time fixing the problem.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Reviewed-by: Antoine Pelisse <apelisse@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current code fixes the path to make it absolute when cloning, but
doesn't consider tilde expansion, so that scenario fails throwing an
exception because /home/myuser/~/my/repository doesn't exists:
$ git clone hg::~/my/repository && cd repository && git fetch
Expand the tilde when checking if the path is absolute, so that we don't
fix a path that doesn't need to be.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some email clients (e.g., claws-mail) display the message body
incorrectly when the charset is not defined explicitly in a
Content-Type header. "git log" generates logs in UTF-8 encoding by
default, so add a Content-Type header declaring that encoding to
the emails the post-receive-email example hook sends.
[jn: also setting the Content-Transfer-Encoding so MTAs know what
kind of mangling might be needed when sending to a non 8-bit clean
SMTP host]
Requested-by: Alexander Gerasiov <gq@debian.org>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Git commands write commit messages in UTF-8 by default, but that
default can be overridden by the [i18n] commitEncoding and
logOutputEncoding settings. With such a setting, the emails written
by the post-receive-email hook use a mixture of encodings:
1. Log messages use the configured log output encoding, which is
meant to be whatever encoding works best with local terminals
(and does not have much to do with what encoding should be used
for email)
2. Filenames are left as is: on Linux, usually UTF-8, and in the Mingw
port (which uses Unicode filesystem APIs), always UTF-8
3. The "This is an automated email" preface uses a project description
from .git/description, which is typically in UTF-8 to support
gitweb.
So (1) is configurable, and (2) and (3) are unconfigurable and
typically UTF-8. Override the log output encoding to always use UTF-8
when writing the email to get the best chance of a comprehensible
single-encoding email.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This way the hook doesn't have to keep being tweaked as porcelain
learns new features like color and pagination.
While at it, replace the "git rev-list | git shortlog" idiom with
plain "git shortlog" for simplicity.
Except for depending less on the value of settings like '[log]
abbrevCommit', no change in output intended.
Signed-off-by: Jonathan Nieder <jrnieder@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
If the libexec directory doesn't exist, git-subtree gets installed as
$prefix/share/libexec/git-core file. This patch creates the directory
before installing git-subtree file into it.
Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
`echo -n` is non-portable. The POSIX specification says:
Conforming applications that wish to do prompting without <newline>
characters or that could possibly be expecting to echo a -n, should
use the printf utility derived from the Ninth Edition system.
Since all of the affected shell scripts use a POSIX shell shebang,
replace `echo -n` invocations with printf.
Signed-off-by: Lukas Fleischer <git@cryptocrack.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
An enhanced "post-receive" hook to send e-mail messages.
* mh/multimail:
post-receive-email: deprecate script in favor of git-multimail
git-multimail: an improved replacement for post-receive-email
A helper to read from a set of format-patch output files or a range
of commits and find those who may have insights to the code that
the changes touch by running a series of "git blame" commands.
* es/contacts:
contrib: contacts: add documentation
contrib: contacts: add mailmap support
contrib: contacts: interpret committish akin to format-patch
contrib: contacts: add ability to parse from committish
contrib: add git-contacts helper
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>
Do not fail to import mercurial commits with empty commit messages.
Signed-off-by: Maurício C Antunes <mauricio.antunes@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a notice to the top of post-receive-email explaining that the
script is no longer under active development and pointing the user to
git-multimail.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
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
Assuming that git-contacts may some day be promoted to a core git
command, the documentation is written and formatted as if it already
belongs in Documentation/ even though it presently resides in
contrib/contacts.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The purpose of git-contacts is to determine a list of people who might
have some interest in a patch or set of changes. It can be used as
git-send-email's --cc-cmd argument or the computed list might be used to
ask for comments on a proposed change. As such, it is important to
report up-to-date email addresses in the computed list rather than
potentially outdated ones recorded with commits. Apply git's mailmap
functionality to the retrieved contacts in order to achieve this goal.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As a convenience, accept the same style <since> committish as accepted
by git-format-patch. For example:
% git contacts origin
will consider commits in the current branch built atop 'origin', just as
"git format-patch origin" will format commits built atop 'origin'.
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For example:
% git contacts R1..R2
Committishes and patch files can be mentioned in the same invocation:
% git contacts R1..R2 extra/*.patch
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This script lists people that might be interested in a patch by going
back through the history for each patch hunk, and finding people that
reviewed, acknowledged, signed, authored, or were Cc:'d on the code the
patch is modifying.
It does this by running git-blame incrementally on each hunk and then
parsing the commit message. After gathering all participants, it
determines each person's relevance by considering how many commits
mentioned that person compared with the total number of commits under
consideration. The final output consists only of participants who pass a
minimum threshold of participation.
Several conditions controlling a person's significance are currently
hard-coded, such as minimum participation level, blame date-limiting,
and -C level for detecting moved and copied lines. In the future, these
conditions may become configurable.
For example:
% git contacts 0001-remote-hg-trivial-cleanups.patch
Felipe Contreras <felipe.contreras@gmail.com>
Jeff King <peff@peff.net>
Max Horn <max@quendi.de>
Junio C Hamano <gitster@pobox.com>
Thus, it can be invoked as git-send-email's --cc-cmd option, among other
possible uses.
This is a Perl rewrite of Felipe Contreras' git-related patch series[1]
written in Ruby.
[1]: http://thread.gmane.org/gmane.comp.version-control.git/226065/
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a command to allow previewing the contents locally before
pushing it out, when working with a MediaWiki remote.
I personally do not think this belongs to Git. If you are working
on a set of AsciiDoc source files, you sure do want to locally
format to preview what you will be pushing out, and if you are
working on a set of C or Java source files, you do want to test it
before pushing it out, too. That kind of thing belongs to your
build script, not to your SCM.
But I'll let it pass, as this is only a contrib/ thing.
* bp/mediawiki-preview:
git-remote-mediawiki: add preview subcommand into git mw
git-remote-mediawiki: add git-mw command
git-remote-mediawiki: factoring code between git-remote-mediawiki and Git::Mediawiki
git-remote-mediawiki: update tests to run with the new bin-wrapper
git-remote-mediawiki: add a git bin-wrapper for developement
wrap-for-bin: make bin-wrappers chainable
git-remote-mediawiki: introduction of Git::Mediawiki.pm
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>
Add git-multimail, a tool for generating notification emails for
pushes to a Git repository. It is largely plug-in compatible with
post-receive-email, and is proposed to eventually replace that script.
The advantages of git-multimail relative to post-receive-email are
described in README.migrate-from-post-receive-email.
git-multimail is organized in a directory contrib/hooks/multimail.
The directory contains:
* git_multimail.py -- a Python module that can generate notification
emails for pushes to a Git repository. The file can be used
directly as a post-receive script (configured via git config
settings), or it can be imported as a Python module and configured
via arbitrary Python code.
* README -- user-level documentation for configuring and using
git-multimail.
* post-receive -- an example of building a post-receive script that
imports git_multimail.py as a Python module, with an example of how
to change the email templates.
* README.migrate-from-post-receive-email -- documentation targeted at
current users of post-receive-email, explaining the differences and
how to migrate a post-receive-email configuration to git-multimail.
* migrate-mailhook-config -- a script that can migrate a user's
post-receive-email configuration options to the equivalent
git-multimail options.
* README.Git -- a short explanation of the relationship between
git-multimail and the rest of the Git project, plus the exact date
and revision when this version was taken from the upstream project.
All but the last file are taken verbatim from the upstream
git-multimail project.
git-multimail is originally derived from post-receive-email and also
incorporates suggestions from the mailing list as well as patches by
the people listed below.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Contributions-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Contributions-by: Ramkumar Ramachandra <artagnon@gmail.com>
Contributions-by: Chris Hiestand <chrishiestand@gmail.com>
Contributions-by: Michiel Holtkamp <git@elfstone.nl>
Contributions-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
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>
In the current state, a user of git-remote-mediawiki can edit the markup text
locally, but has to push to the remote wiki to see how the page is rendererd.
Add a new 'git mw preview' command that allows rendering the markup text on
the remote wiki without actually pushing any change on the wiki.
This uses Mediawiki's API to render the markup and inserts it in an actual
HTML page from the wiki so that CSS can be rendered properly. Most links
should work when the page exists on the remote.
Signed-off-by: Benoit Person <benoit.person@ensimag.fr>
Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For now, git-remote-mediawiki is only a remote-helper. This patch adds a new
toolset script in which we will be able to build new tools for
git-remote-mediawiki.
This toolset uses a subcommand-mechanism to launch the proper action. For now
only the 'help' subcommand is implemented. It also provides some generic code
for the verbose and help command line options.
Signed-off-by: Benoit Person <benoit.person@ensimag.fr>
Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For now, Git::Mediawiki contains nothing.
This first patch moves some of git-remote-mediawiki.perl's factorisable code
into Git::Mediawiki. In the same time, it removes the side effects of that code
and renames the fucntions and constants moved to expose a better API.
Signed-off-by: Benoit Person <benoit.person@ensimag.fr>
Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Until now, if git-remote-mediawiki was not installed, the test suite
copied it to the toplevel directory. This solution pollutes the
directory with untracked files. Plus, we would need to copy the new
git-mw.perl file to test it too.
Signed-off-by: Benoit Person <benoit.person@ensimag.fr>
Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The introduction of the Git::Mediawiki package makes it impossible to test,
without installation, git-remote-mediawiki and git-mw.
Using a git bin-wrapper enables us to define proper $GITPERLLIB to force the
use of the developement version of the Git::Mediawiki package, bypassing its
installed version if any.
An alternate solution was to 'install' all the files required at each build
but it pollutes the toplevel with untracked files.
Signed-off-by: Benoit Person <benoit.person@ensimag.fr>
Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We would want to allow the user to preview what he has edited locally
before pushing it out (and thus creating a non-removable revision in
the mediawiki's history).
This patch introduces a new perl package in which we will be able to
share code between that new tool and the remote helper:
git-remote-mediawiki.perl.
A perl package offers the best way to handle such case: Each script
can select what should be imported in its namespace. The package
namespacing limits the use of side effects in the shared code.
An alternate solution is to concatenate a "toolset" file with each
*.perl when 'make'-ing the project. In that scheme, everything is
imported in the script's namespace. Plus, files should be renamed in
order to chain to Git's toplevel makefile. Hence, this solution is not
acceptable.
Signed-off-by: Benoit Person <benoit.person@ensimag.fr>
Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit e83d36b66f turned "print STDOUT" into "print {*STDOUT}", as
suggested by perlcritic. Unfortunately, it also changed two "binmode
STDOUT" calls the same way, which does not work and yield a "Not a GLOB
reference" error.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
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>
__git_ps1() runs the '$(git symbolic-ref HEAD)' command substitution
to find out whether we are on a branch and to find out the name of
that branch. This imposes the overhead of fork()ing a subshell and
fork()+exec()ing a git process.
Since HEAD is in most cases a single-line file and the symbolic ref
format is quite simple to recognize and parse, read and parse it using
only bash builtins, thereby sparing all that fork()+exec() overhead.
Don't display the git prompt if reading HEAD fails, because a readable
HEAD is required for a git repository. HEAD can also be a symlink
symbolic ref (due to 'core.preferSymlinkRefs'), so use bash builtins
for reading HEAD only when HEAD is not a symlink.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
During an ongoing interactive rebase __git_ps1() finds out the name of
the rebased branch, the total number of patches and the number of the
current patch by executing a '$(cat .git/rebase-merge/<FILE>)' command
substitution for each. That is not quite the most efficient way to
read single line single word files, because it imposes the overhead of
fork()ing a subshell and fork()+exec()ing 'cat' several times.
Use the 'read' bash builtin instead to avoid those overheads.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
__git_ps1() finds out the path to the repository by using the
__gitdir() helper function. __gitdir() is basically just a wrapper
around 'git rev-parse --git-dir', extended with support for
recognizing a remote repository given as argument, to use the path
given on the command line, and with a few shortcuts to recognize a git
repository in cwd or at $GIT_DIR quickly without actually running 'git
rev-parse'. However, the former two is only necessary for the
completion script but makes no sense for the bash prompt, while the
latter shortcuts are performance optimizations __git_ps1() can do
without (they just avoid the overhead of fork()+exec()ing a git
process).
Run 'git rev-parse --git-dir' directly in __git_ps1(), because it will
allow this patch series to combine several $(git rev-parse ...)
command substitutions in the main code path, and the overall
performance benefit will far outweigh the loss of those few shortcuts
in __gitdir(). Furthermore, since __gitdir() is not needed anymore
for the prompt, remove it from the prompt script finally eliminating
its duplication between the prompt and completion scripts. Also
remove the comment from the completion script warning about this code
duplication.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
... to gain one level of indentation for the bulk of the function.
(The patch looks quite unreadable, you'd better check it with 'git
diff -w'.)
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() runs 'cut -c1-7 .git/HEAD' to
show the 7 hexdigits abbreviated commit object name in the prompt.
Obviously, this neither respects core.abbrev nor produces a unique
object name.
Fix this by using 'git rev-parse --short HEAD' instead and adjust the
corresponding test to use non-standard number of hexdigits.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
* cm/remote-mediawiki-perlcritique: (31 commits)
git-remote-mediawiki: make error message more precise
git-remote-mediawiki: add a perlcritic rule in Makefile
git-remote-mediawiki: add a .perlcriticrc file
git-remote-mediawiki: clearly rewrite double dereference
git-remote-mediawiki: fix a typo ("mediwiki" instead of "mediawiki")
git-remote-mediawiki: put non-trivial numeric values in constants.
git-remote-mediawiki: don't use quotes for empty strings
git-remote-mediawiki: replace "unless" statements with negated "if" statements
git-remote-mediawiki: brace file handles for print for more clarity
git-remote-mediawiki: modify strings for a better coding-style
git-remote-mediawiki: put long code into a subroutine
git-remote-mediawiki: remove import of unused open2
git-remote-mediawiki: check return value of open
git-remote-mediawiki: assign a variable as undef and make proper indentation
git-remote-mediawiki: rename a variable ($last) which has the name of a keyword
git-remote-mediawiki: remove unused variable $entry
git-remote-mediawiki: turn double-negated expressions into simple expressions
git-remote-mediawiki: change the name of a variable
git-remote-mediawiki: add newline in the end of die() error messages
git-remote-mediawiki: change style in a regexp
...
Updates the code to make it more easy to switch mediawiki version when
testing. Before that, the version number was partly hardcoded, partly
in a var.
Signed-off-by: Benoit Person <benoit.person@ensimag.fr>
Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In subroutine parse_command, error messages were not correct. For the "import"
function, having too much or incorrect arguments displayed both
"invalid arguments", while it displayed "too many arguments" for the "option"
functions under the same conditions.
Separate the two error messages in both cases.
Signed-off-by: Célestin Matte <celestin.matte@ensimag.fr>
Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Option "-2" launches perlcritic with level 2. Levels go from 5 (most pertinent)
to 1. Rules of level 1 are mostly a question of style, and are therefore
ignored.
Signed-off-by: Célestin Matte <celestin.matte@ensimag.fr>
Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Such a file allows to configure perlcritic.
Here, it is used to remove many unwanted rules and configure one to
remove unwanted warnings.
Signed-off-by: Célestin Matte <celestin.matte@ensimag.fr>
Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
@$var structures are re-written in the following way: @{$var}
It makes them more readable.
Signed-off-by: Célestin Matte <celestin.matte@ensimag.fr>
Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Non-trivial numeric values (e.g., different from 0, 1 and 2) are placed in
constants at the top of the code to be easily modifiable and to make more sense
Signed-off-by: Célestin Matte <celestin.matte@ensimag.fr>
Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Empty strings are replaced by an $EMPTY constant.
Signed-off-by: Célestin Matte <celestin.matte@ensimag.fr>
Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This follows the following rule:
InputOutput::RequireBracedFileHandleWithPrint (Severity: 1)
The `print' and `printf' functions have a unique syntax that supports an
optional file handle argument. Conway suggests wrapping this argument in
braces to make it visually stand out from the other arguments. When you
put braces around any of the special package-level file handles like
`STDOUT', `STDERR', and `DATA', you must the `'*'' sigil or else it
won't compile under `use strict 'subs''.
print $FH "Mary had a little lamb\n"; #not ok
print {$FH} "Mary had a little lamb\n"; #ok
print STDERR $foo, $bar, $baz; #not ok
print {STDERR} $foo, $bar, $baz; #won't compile under 'strict'
print {*STDERR} $foo, $bar, $baz; #perfect!
Signed-off-by: Célestin Matte <celestin.matte@ensimag.fr>
Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
- strings which don't need interpolation are single-quoted for more clarity and
slight gain of performance
- interpolation is preferred over concatenation in many cases, for more clarity
- variables are always used with the ${} operator inside strings
- strings including double-quotes are written with qq() so that the quotes do
not have to be escaped
Signed-off-by: Célestin Matte <celestin.matte@ensimag.fr>
Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Explicitly assign local variable $/ as undef and make a proper
one-instruction-by-line indentation
Signed-off-by: Célestin Matte <celestin.matte@ensimag.fr>
Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Local variable $url has the same name as a global variable. Changing the name
of the local variable prevents future possible misunderstanding.
Signed-off-by: Célestin Matte <celestin.matte@ensimag.fr>
Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In this regexp, ' |\n' is used, whereas its equivalent '[ \n]', which is
clearer, is used elsewhere. Make the style coherent.
Signed-off-by: Célestin Matte <celestin.matte@ensimag.fr>
Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
