"--exec-path" looks to the completion script like an unambiguous
successful completion, but it is wrong to emit a SP after it as if
declaring that we are done with completion; the user could be trying
to do
so the most helpful thing to do is to leave out the trailing space and
leave it to the operator to type an equal sign or carriage return
according to the situation.
[fc: added tests]
Cc: Andreas Schwab <schwab@linux-m68k.org> Reported-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
I tentatively named the release notes "1.7.11" but this may have to
be renamed to "1.8" or some other name later. Let's see how well
we would do during this cycle.
gitweb: Fix unintended "--no-merges" for regular Atom feed
The print_feed_meta() subroutine generates links for feeds with and
without merges, in RSS and Atom formats. However because %href_params
was not properly reset, it generated links with "--no-merges" for all
except the very first link.
Before:
<link rel="alternate" title="[..] - Atom feed" href="/?p=.git;a=atom;opt=--no-merges" type="application/atom+xml" />
<link rel="alternate" title="[..] - Atom feed (no merges)" href="/?p=.git;a=atom;opt=--no-merges" type="application/atom+xml" />
After:
<link rel="alternate" title="[..] - Atom feed" href="/?p=.git;a=atom" type="application/atom+xml" />
<link rel="alternate" title="[..] - Atom feed (no merges)" href="/?p=.git;a=atom;opt=--no-merges" type="application/atom+xml" />
Signed-off-by: Sebastian Pipping <sebastian@pipping.org> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Check if we even have a parameter before checking its value. Running
this command without any arguments may not make a lot of sense, but
reacting with a segmentation fault is unduly harsh.
While we're at it, avoid casting argv by declaring it const right away.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a Makefile to run subtree tests. This is largely copied
from the standard test suite with irrelevant targets removed
and some paths altered to account for where subtree tests live.
Signed-off-by: David A. Greene <greened@obbligato.org>
Build git-subtree in its contrib directory and install from there.
The main Makefile no longer discovers subcommands build in the main
build area so we cannot count on it to install git-subtree. The user
should make && make install in contrib/subtree to install git-subtree.
Change the rule to install the git-subtree manpage. The main
Documentation area doesn't directly support installing documentation
from other directories so the user will have to do that from within
contrib/subtree for now.
Signed-off-by: David A. Greene <greened@obbligato.org>
* tr/cache-tree:
t0090: be prepared that 'wc -l' writes leading blanks
reset: update cache-tree data when appropriate
commit: write cache-tree data when writing index anyway
Refactor cache_tree_update idiom from commit
Test the current state of the cache-tree optimization
Add test-scrap-cache-tree
Merge branch 'cb/maint-t5541-make-server-port-portable' into maint-1.7.8
* cb/maint-t5541-make-server-port-portable:
t5541: check error message against the real port number used
remote-curl: Fix push status report when all branches fail
Merge branch 'tr/maint-bundle-boundary' into maint-1.7.8
* tr/maint-bundle-boundary:
bundle: keep around names passed to add_pending_object()
t5510: ensure we stay in the toplevel test dir
t5510: refactor bundle->pack conversion
Merge branch 'tr/maint-bundle-long-subject' into maint-1.7.8
* tr/maint-bundle-long-subject:
t5704: match tests to modern style
strbuf: improve strbuf_get*line documentation
bundle: use a strbuf to scan the log for boundary commits
bundle: put strbuf_readline_fd in strbuf.c with adjustments
gitk: fix tabbed preferences construction when using tcl 8.4
In 8.5 the incr command creates the target variable if it does not exist
but in 8.4 using incr on a non-existing variable raises an error. Ensure
we have created our counter variable when creating the tabbed dialog for
non-themed preferences.
Reported-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Portuguese Portuguese translations from Marco Sousa via Jiang Xin
* 'master' of git://github.com/git-l10n/git-po:
l10n: Add the Dutch translation team and initialize nl.po
l10n: Inital Portuguese Portugal language (pt_PT)
l10n: Improve zh_CN translation for Git 1.7.10-rc3
v1.7.9-8-g270a344 (config: stop using config_exclusive_filename) replaced
config_exclusive_filename with given_config_file. In one case this
resulted in a self-assignment, which is reported by clang as a warning.
Remove the useless code.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Why not just git grep -E ...?
That wouldn't work then the doubled words are separated by a newline.
This is derived from a Makefile syntax-check rule in gnulib's maint.mk:
http://git.sv.gnu.org/cgit/gnulib.git/tree/top/maint.mk
Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'master' of git://github.com/git-l10n/git-po:
Add url of Swedish l10n team in TEAMS file
l10n: Review zh_CN translation for Git 1.7.10-rc1
Update Swedish translation (724t0f0u).
l10n: Update zh_CN translation for Git 1.7.10-rc1
l10n: Update git.pot (1 new message)
$COLUMNS must be unset to not interfere with the tests. The tests
already ignore the terminal size because output is redirected to a
file, but COLUMNS overrides terminal size detection and changes the
test output away from the standard 80.
Reported-by: Jeff King <peff@peff.net> Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
- Update for 1.7.10-rc1.
- Add a missing -e when generaring the "Untracked files" message.
- Fixed some wordings after playing with the localized version.
Documentation: improve description of GIT_EDITOR and preference order
Previously GIT_EDITOR was not listed in git(1) "Environment Variables" section,
which could be very confusing to users. Include it in "other" subsection along
with a link to git-var(1), since that is the page that fully describes all
places where editor can be set and also their preference order.
Also, git-var(1) did not say that hardcoded fallback 'vi' may have been changed
at build time. A user could be puzzled if 'nano' pops up even when none of the
mentioned environment vars or config.editor are set. Clarify this.
Ideally, the build system should be changed to reflect the chosen fallback
editor when creating the man pages. Not sure if that is even possible though.
Signed-off-by: Rodrigo Silva (MestreLion) <linux@rodrigosilva.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
documentation: fix alphabetic ordered list for git-rebase man page
An alphabetic ordered list (a.) is converted to numerical in
the man page (1.) so context comments naming 'a' were confusing,
fix that by not using ordered list notation for 'a' anb 'b' items.
Signed-off-by: Nelson Benitez Leon <nelsonjesus.benitez@seap.minhap.es> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge gitk changes from Paul Mackerras at git://ozlabs.org/~paulus/gitk
* git://ozlabs.org/~paulus/gitk:
gitk: Teach gitk to respect log.showroot
gitk: Add menu items for comparing a commit with the marked commit
gitk: Speed up resolution of short SHA1 ids
gitk: Use symbolic font names "sans" and "monospace" when available
gitk: Skip over AUTHOR/COMMIT_DATE when searching all fields
gitk: Make "git describe" output clickable, too
gitk: Fix the display of files when filtered by path
gitk: Use a tabbed dialog to edit preferences
gitk: Use "gitk: repo-top-level-dir" as window title
In early days, all projects managed by git (except for git itself) had the
product of a fairly mature development history in their first commit, and
it was deemed unnecessary clutter to show additions of these thousands of
paths as a patch.
"git log" learned to show the patch for the initial commit without requiring
--root command line option at 0f03ca9 (config option log.showroot to show
the diff of root commits, 2006-11-23).
Teach gitk to respect log.showroot.
[paulus@samba.org: Cleaned up the Tcl a bit, use --bool on the
git config call]
Signed-off-by: Marcus Karlsson <mk@acc.umu.se> Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Add menu items for comparing a commit with the marked commit
Sometimes one wants to see the different between two commits that are
a long distance apart in the graph display. This is difficult to do
with the "Diff this -> selected" and "Diff selected -> this" menu
items because the need to maintain the selection means that one can't
use the find facilities or the reference list window to navigate from
one to the other.
This provides an alternative using the mark. Having found one commit,
one marks it with the "Mark this commit" menu item, then navigates to
the other commit and uses the new "Diff this -> marked commit" and/or
"Diff marked commit -> this" menu items.
Even though 1.7.9.x series does not open the editor by default
when merging in general, it does do so in one occassion: when
merging an annotated tag. And worse yet, there is no good way
for older scripts to decline this.
Backport the support for GIT_MERGE_AUTOEDIT environment variable
from 1.7.10 track to help those stuck on 1.7.9.x maintenance
track.
On large repositories such as the Linux kernel, it can take quite a
noticeable time (several seconds) for gitk to resolve short SHA1 IDs
to their long form. This speeds up the process by maintaining lists
of IDs indexed by the first 4 characters of the SHA1 ID, speeding up
the search by a factor of 65536 on large repositories.
gitk: Use symbolic font names "sans" and "monospace" when available
The following only concerns systems using X and the client-side font
rendering framework from freedesktop.org. Windows and Mac OS X are
not affected.
Starting with version 8.5, Tk uses freetype and fontconfig by default
to render fonts on platforms that support it. Gitk currently defaults
to the font Helvetica for the interface and Courier for diffs, and
both unfortunately look rather bad on screen in the default
configuration on many Linux distros with anti-aliasing and poor
hinting.
It is better to default to "sans" and "monospace", which are mapped by
fontconfig to some appropriate font of the sysadmin and user's
choosing (typically Bitstream Vera Sans and Mono). The result looks
more sensible and it makes gitk feel like a well-behaved software
citizen since its fonts match other native apps.
This patch does not change the appearance of gitk for users that have
already run it, since gitk uses the remembered UI and diff font names
from ~/.gitk.
Requested-by: Michael Biebl <biebl@debian.org> Reviewed-by: Josh Triplett <josh@joshtriplett.org> Acked-by: Mark Hills <mark@pogo.org.uk> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Skip over AUTHOR/COMMIT_DATE when searching all fields
This prevents a search for a number like "105" on "All Fields" from
matching against the raw author and commit timestamps. These
timestamps were already not searchable by themselves, and the
displayed format does not match the query string anyway.
Signed-off-by: Frédéric Brière <fbriere@fbriere.net> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
Automake's contribution guidelines suggest using "git describe" output
in commit logs to reference previous commits. By contrast, in
coreutils, I had acquired the habit of using a bare SHA1 prefix (8 hex
digits), since gitk creates clickable links for that, and not for "git
describe" output.
I prefer the readability of the full "git describe" output, yet want
to retain the gitk links, so this renders as clickable not just
SHA1-like strings, but also an SHA1-like string that is prefixed by
"-g".
Signed-off-by: Jim Meyering <meyering@redhat.com> Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Fix the display of files when filtered by path
Launching 'gitk -- .' or 'gitk -- ..\t' restricts the display to files
under the given directory but the file list is left empty. This is because
the path_filter function fails to match the filenames which are relative
to the working tree to the filter which is filessytem relative.
This solves the problem by making both names fully qualified filesystem
paths before performing the comparison.
Tested-by: David Aguilar <davvid@gmail.com> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
This commit converts the user preferences dialog into a tabbed property
sheet grouping general properties, colours and font selections onto
separate pages. The previous implementation was exceeding the screen
height on some systems and this avoids such problems and permits extension
using new pages in the future.
If themed Tk is unavailable or undesired a reasonable facsimile of the
tabbed notebook widget is used instead.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Use "gitk: repo-top-level-dir" as window title
Previously, when run in a subdirectory, gitk would show the name
of this subdirectory as title, which was misleading. When run with
GIT_DIR set, it would show the cwd, which is even more misleading.
In case of non-bare repos, the .git suffix in the path is skipped.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
perl/Makefile: install Git::I18N under NO_PERL_MAKEMAKER
When I added the i18n infrastructure in v1.7.8-rc2-1-g5e9637c I forgot
to install Git::I18N also when NO_PERL_MAKEMAKER=YesPlease was
set. Change the generation of the fallback perl.mak file to do that.
Now Git/I18N.pm is installed alongside Git.pm in such a way that
anything that uses GITPERLLIB will find it.
Reported-by: Tom G. Christensen <tgc@statsbiblioteket.dk> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The code to validate the history connectivity between old refs and new
refs used by fetch and receive-pack, introduced in 1.7.8, was grossly
inefficient and unnecessarily tried to re-validate integrity of individual
objects. This essentially reverts that performance regression.
Merge "two fixes for fast-import's 'ls' command" from Jonathan
Andrew Sayers noticed that the svn-fe | git fast-import pipeline
mishandles a subversion history that copies the root directory to a
sub-directory (e.g. doing `svn cp . trunk` to standardise your
layout). As David Barr explained, the bug arises when the following
command is sent to git fast-import:
'ls' SP ':1' SP LF
Instead of reading back what is at the root of r1, it unconditionally
reports the path as missing.
After sleeping on it, here are two patches for 'maint'. One plugs a
memory leak. The other ensures that trying to pass an empty path to
the 'ls' command results in an error message that can help the
frontend author instead of the silently broken conversion Andrew
found.
Then we can carefully add 'ls ""' support in 1.7.11.
* commit 'refs/pull-request-tags/jn/maint-fast-import-empty-ls':
fast-import: don't allow 'ls' of path with empty components
fast-import: leakfix for 'ls' of dirty trees
* th/git-diffall:
contrib/diffall: fix cleanup trap on Windows
contrib/diffall: eliminate duplicate while loops
contrib/diffall: eliminate use of tar
contrib/diffall: create tmp dirs without mktemp
contrib/diffall: comment actual reason for 'cdup'
Git 1.7.8 introduced an object and history re-validation step after
"fetch" or "push" causes new history to be added to a receiving
repository. This is to protect a malicious server or pushing client from
corrupting the repository by taking advantage of an existing corrupt
object that is unconnected to existing history.
But this check is way over-pessimistic. During "fetch" or "receive-pack"
(the server side of "push"), unpack-objects and index-pack already
validate individual objects that are received, and the only thing we would
want to catch are corrupted objects that already happen to exist in our
repository but are not referenced from our refs. Such objects must have
been written by an earlier run of our codepaths that write out loose
objects or packfiles, and they must have done the validation of individual
objects when they did so. The only thing left to worry about is the
connectivity integrity, which can be checked with "rev-list --objects",
which is much cheaper. We have been paying the 5x to 8x runtime overhead
the --verify-objects often adds for no real gain.
Revert check_everything_connected() not to use this over-pessimistic
check.
Credit goes to Nguyễn Thái Ngọc Duy, who originally identified the
performance regression and endured multiple rounds of reviews to fix it.