* rh/remote-hg-bzr-updates:
remote-bzr, remote-hg: fix email address regular expression
test-hg.sh: help user correlate verbose output with email test
test-hg.sh: fix duplicate content strings in author tests
test-hg.sh: avoid obsolete 'test' syntax
test-hg.sh: eliminate 'local' bashism
test-bzr.sh, test-hg.sh: prepare for change to push.default=simple
test-bzr.sh, test-hg.sh: allow running from any dir
test-lib.sh: convert $TEST_DIRECTORY to an absolute path
Our current scheme for naming packfiles is to calculate the
sha1 hash of the sorted list of objects contained in the
packfile. This gives us a unique name, so we are reasonably
sure that two packs with the same name will contain the same
objects.
It does not, however, tell us that two such packs have the
exact same bytes. This makes things awkward if we repack the
same set of objects. Due to run-to-run variations, the bytes
may not be identical (e.g., changed zlib or git versions,
different source object reuse due to new packs in the
repository, or even different deltas due to races during a
multi-threaded delta search).
In theory, this could be helpful to a program that cares
that the packfile contains a certain set of objects, but
does not care about the particular representation. In
practice, no part of git makes use of that, and in many
cases it is potentially harmful. For example, if a dumb http
client fetches the .idx file, it must be sure to get the
exact .pack that matches it. Similarly, a partial transfer
of a .pack file cannot be safely resumed, as the actual
bytes may have changed. This could also affect a local
client which opened the .idx and .pack files, closes the
.pack file (due to memory or file descriptor limits), and
then re-opens a changed packfile.
In all of these cases, git can detect the problem, as we
have the sha1 of the bytes themselves in the pack trailer
(which we verify on transfer), and the .idx file references
the trailer from the matching packfile. But it would be
simpler and more efficient to actually get the correct
bytes, rather than noticing the problem and having to
restart the operation.
This patch simply uses the pack trailer sha1 as the pack
name. It should be similarly unique, but covers the exact
representation of the objects. Other parts of git should not
care, as the pack name is returned by pack-objects and is
essentially opaque.
One test needs to be updated, because it actually corrupts a
pack and expects that re-packing the corrupted bytes will
use the same name. It won't anymore, but we can easily just
use the name that pack-objects hands back.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
commit -v: strip diffs and submodule shortlogs from the commit message
When using the '-v' option of "git commit" the diff added to the commit
message temporarily for editing is stripped off after the user exited the
editor by searching for "\ndiff --git " and truncating the commmit message
there if it is found.
But this approach has two problems:
- when the commit message itself contains a line starting with
"diff --git" it will be truncated there prematurely; and
- when the "diff.submodule" setting is set to "log", the diff may
start with "Submodule <hash1>..<hash2>", which will be left in
the commit message while it shouldn't.
Fix that by introducing a special scissor separator line starting with the
comment character ('#' or the core.commentChar config if set) followed by
two lines describing what it is for. The scissor line - which will not be
translated - is used to reliably detect the start of the diff so it can be
chopped off from the commit message, no matter what the user enters there.
Turn a known test failure fixed by this change into a successful test;
also add one for a diff starting with a submodule log and another one for
proper handling of the comment char.
Reported-by: Ari Pollak <ari@debian.org> Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
replace {pre,suf}fixcmp() with {starts,ends}_with()
Leaving only the function definitions and declarations so that any
new topic in flight can still make use of the old functions, replace
existing uses of the prefixcmp() and suffixcmp() with new API
functions.
The change can be recreated by mechanically applying this:
prefixcmp() and suffixcmp() share the common "cmp" suffix that
typically are used to name functions that can be used for ordering,
but they can't, because they are not antisymmetric:
We in fact do not use these functions for ordering. Replace them
with functions that just check for equality.
Add starts_with() and end_with() that will be used to replace
prefixcmp() and suffixcmp(), respectively, as the first step. These
are named after corresponding functions/methods in programming
languages, like Java, Python and Ruby.
In vcs-svn/fast_export.c, there was already an ends_with() function
that did the same thing. Let's use the new one instead while at it.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/remote: remove postfixcmp() and use suffixcmp() instead
Commit 8cc5b290 (git merge -X<option>, 25 Nov 2009) introduced
suffixcmp() with nearly the same implementation as postfixcmp()
that already existed since commit 211c8968 (Make git-remote a
builtin, 29 Feb 2008).
The only difference between the two implementations is that,
when the string is smaller than the suffix, one implementation
returns 1 while the other one returns -1.
But, as postfixcmp() is only used to compare for equality, the
distinction does not matter and does not affect the correctness of
this patch.
As postfixcmp() has always been static in builtin/remote.c
and is used nowhere else, it makes more sense to remove it
and use suffixcmp() instead in builtin/remote.c, rather than
to remove suffixcmp().
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jn/mediawiki-makefile-updates:
git-remote-mediawiki build: handle DESTDIR/INSTLIBDIR with whitespace
git-remote-mediawiki build: make 'install' command configurable
git-remote-mediawiki: honor DESTDIR in "make install"
git-remote-mediawiki: do not remove installed files in "clean" target
Fix a rather longstanding corner-case bug in twoway "reset to
there" merge, which is most often seen in "git am --abort".
* jk/two-way-merge-corner-case-fix:
t1005: add test for "read-tree --reset -u A B"
t1005: reindent
unpack-trees: fix "read-tree -u --reset A B" with conflicted index
People often wished a way to tell "git log --branches" (and "git
log --remotes --not --branches") to exclude some local branches
from the expansion of "--branches" (similarly for "--tags", "--all"
and "--glob=<pattern>"). Now they have one.
* jc/ref-excludes:
rev-parse: introduce --exclude=<glob> to tame wildcards
rev-list --exclude: export add/clear-ref-exclusion and ref-excluded API
rev-list --exclude: tests
document --exclude option
revision: introduce --exclude=<glob> to tame wildcards
Issue "100 Continue" responses to help use of GSS-Negotiate
authentication scheme over HTTP transport when needed.
* bc/http-100-continue:
remote-curl: fix large pushes with GSSAPI
remote-curl: pass curl slot_results back through run_slot
http: return curl's AUTHAVAIL via slot_results
When two processes created one loose object file each, which fell
into the same fan-out bucket that previously did not have any
objects, they both tried to do an equivalent of
before writing into their file .git/objects/$fanout/$remainder,
one of which could have failed unnecessarily when the second
invocation of mkdir found that the directory already has been
created by the first one.
* jh/loose-object-dirs-creation-race:
sha1_file.c:create_tmpfile(): Fix race when creating loose object dirs
* jk/robustify-parse-commit:
checkout: do not die when leaving broken detached HEAD
use parse_commit_or_die instead of custom message
use parse_commit_or_die instead of segfaulting
assume parse_commit checks for NULL commit
assume parse_commit checks commit->object.parsed
log_tree_diff: die when we fail to parse a commit
A behavior change, but a worthwhile one: "git submodule foreach"
was treating its arguments as part of a single command to be
concatenated and passed to a shell, making writing buggy
scripts too easy.
This patch preserves the old "just pass it to the shell" behavior
when a single argument is passed to 'git submodule foreach' and
moves to a new "skip the shell and use the arguments passed
unmolested" behavior when more than one argument is passed.
The old behavior (always concatenating and passing to the shell)
was similar to the 'ssh' command, while the new behavior (switching
on the number of arguments) is what 'xterm -e' does.
May need more thought to make sure this change is advertised well
so that scripts that used multiple arguments but added their own
extra layer of quoting are not broken.
* ak/submodule-foreach-quoting:
submodule foreach: skip eval for more than one argument
In t5000, we test the built-in ".tar.gz" config for
git-archive. To make our tests portable, we check that we
have a way to both gzip and gunzip, and we respected
environment variables to point to alternate commands for
doing these operations.
However, the $GZIP variable did not actually do anything, as
changing it would not affect the baked-in value in
archive-tar.c. Moreover, setting the variable $GZIP
influences gzip itself. From the gzip man page:
The environment variable GZIP can hold a set of default
options for gzip. These options are interpreted first and
can be overwritten by explicit command line parameters.
We could rename this variable, and use it to set up custom
config (or even have a Makefile knob to affect the built
binary), but it is not worth the trouble; nobody has ever
reported a problem with the baked-in default, and they can
always change it via config if they need to. Let's just drop
the variable and use "gzip" in the test (keeping the
prerequisite, of course).
While we're at it, we can drop the GUNZIP variable and
prerequisite; it uses "gzip -d", so if we have GZIP, we
will have both.
We can also use test_lazy_prereq for the gzip prerequisite,
which is simpler and behaves more consistently with the rest
of git (e.g., by making output available when the test is
run with "-v").
Noticed-by: Christian Hesse <mail@eworm.de> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Bug 6530 [1] in glibc causes "git show v0.99.6~1" to fail with error
"your vsnprintf is broken". The workaround avoids that, but it
corrupts system error messages in non-C locales.
The bug has been fixed since 2.17. We could know running glibc version
with gnu_get_libc_version(). But version is not a sure way to detect
the bug because downstream may back port the fix to older versions. Do
a runtime test that immitates the call flow that leads to "your
vsnprintf is broken". Only enable the workaround if the test fails.
Tested on Gentoo Linux, glibc 2.16.0 and 2.17, amd64.
push: also use "upstream" mapping when pushing a single ref
When the user is using the 'upstream' mode, these commands:
$ git push
$ git push origin
would find the 'upstream' branch for the current branch, and then
push the current branch to update it. However, pushing a single
branch explicitly, i.e.
would not go through the same ref mapping process, and ends up
updating the branch at 'origin' of the same name, which may not
necessarily be the upstream of the branch being pushed.
In the spirit similar to the previous one, map a colon-less refspec
using the upstream mapping logic.
Since f2690487 (fetch: opportunistically update tracking refs,
2013-05-11), we stopped taking a non-storing refspec given on the
command line of "git fetch" literally, and instead started mapping
it via remote.$name.fetch refspecs. This allows
$ git fetch origin master
from the 'origin' repository, which is configured with
to reduce surprises and improve usability. Before that change, a
refspec on the command line without a colon was only to fetch the
history and leave the result in FETCH_HEAD, without updating the
remote-tracking branches.
When you are simulating a fetch from you by your mothership with a
push by you into your mothership, instead of having:
Because we so far did not make the corresponding change to the push
side, this command:
satellite$ git push mothership master
does _not_ allow you on the satellite to only push 'master' out but
still to the usual destination (i.e. refs/remotes/satellite/master).
Implement the logic to map an unqualified refspec given on the
command line via the remote.$name.push refspec. This will bring a
bit more symmetry between "fetch" and "push".
Git used to trim the trailing slash, and make the command equivalent
to 'git mv file no-such-dir', which created the file no-such-dir
(while the trailing slash explicitly stated that it could only be a
directory).
This patch skips the trailing slash removal for the destination
path. The path with its trailing slash is passed to rename(2),
which errors out with the appropriate message:
$ git mv file no-such-dir/
fatal: renaming 'file' failed: Not a directory
Original-patch-by: Duy Nguyen <pclouds@gmail.com> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
send-email: set SSL options through IO::Socket::SSL::set_client_defaults
When --smtp-encryption=ssl, we use a Net::SMTP::SSL connection,
passing its ->new all the options that would otherwise go to
Net::SMTP->new (most options) and IO::Socket::SSL->start_SSL (for the
SSL options).
However, while Net::SMTP::SSL replaces the underlying socket class
with an SSL socket, it does nothing to allow passing options to that
socket. So the SSL-relevant options are lost.
Fortunately there is an escape hatch: we can directly set the options
with IO::Socket::SSL::set_client_defaults. They will then persist
within the IO::Socket::SSL module.
Signed-off-by: Thomas Rast <tr@thomasrast.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
send-email: --smtp-ssl-cert-path takes an argument
35035bb (send-email: be explicit with SSL certificate verification,
2013-07-18) forgot to specify that --smtp-ssl-cert-path takes a string
argument. This means that the option could not actually be used as
intended. Presumably noone noticed because it's much easier to set it
through configs anyway.
Add the required "=s".
Signed-off-by: Thomas Rast <tr@thomasrast.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
We forgot to pass the Debug option through to Net::SMTP::SSL->new --
which is the same as Net::SMTP->new. This meant that with security
set to SSL, we would never enable debug output.
Pass through the flag.
Signed-off-by: Thomas Rast <tr@thomasrast.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/push.c: use strbuf instead of manual allocation
The command line arguments given to "git push" are massaged into
a list of refspecs in set_refspecs() function. This was implemented
using xmalloc, strcpy and friends, but it is much easier to read if
done using strbuf.
When the built-in "git tar-tree" command (a thin wrapper around "git
archive") was removed in 925ceccf (tar-tree: remove deprecated
command, 2013-11-10), the build continued to install a non-functioning
git-tar-tree command in gitexecdir by mistake:
The list of links in gitexecdir is populated from BUILTIN_OBJS, which
includes builtin/tar-tree.o to implement "git get-tar-commit-id".
Rename the get-tar-commit-id source file to builtin/get-tar-commit-id.c
to reflect its purpose and fix 'make install'.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
ref-iteration doc: add_submodule_odb() returns 0 for success
The usage sample of add_submodule_odb() function in the Submodules
section expects non-zero return value for success, but the function
actually reports success with zero.
Helped-by: René Scharfe <l.s.r@web.de> Reviewed-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Nick Townsend <nick.townsend@mac.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
submodule: do not copy unknown update mode from .gitmodules
When submodule.$name.update is given as hint from the upstream in
the .gitmodules file, we used to blindly copy it to .git/config,
unless there already is a value defined for the submodule.
However, there is no reason to expect that the update mode hinted by
the upstream is available in the version of Git the user is using,
and a really custom "!cmd" prepared by an upstream person running on
Linux may not even be available to a user on Windows. It is simply
irresponsible to copy the setting blindly and to attempt to use it
during a later "submodule update" without validating it first.
Just show the suggested value to the diagnostic output, and set the
value to 'none' in the configuration, if it is not one of the ones
that are known to be supported by this version of Git.
Helped-by: Jens Lehmann <Jens.Lehmann@web.de> Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When allocating the slab, the code accidentally computed the array
size from s->slab (an elemtype**). The slab is an array of elemtype*,
however, so we should take the size of *s->slab.
Noticed-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Thomas Rast <tr@thomasrast.ch> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This gives line-log support to gitk, by exploiting the new support for
processing and showing "inline" diffs straight from the git-log
output.
Note that we 'set allknown 0', which is a bit counterintuitive since
this is a "known" option. But that flag prevents gitk from thinking
it can optimize the view by running rev-list to see the topology; in
the -L case that doesn't work.
Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Paul Mackerras <paulus@samba.org>
So far we just parsed everything after the headers into the "comment"
bit of $commitinfo, including notes and -- if you gave weird options
-- the diff.
Split out the diff, if any, into a separate field. It's easy to
recognize, since it always starts with /^diff/ and is preceded by an
empty line.
We take care to snip away said empty line. The display code already
properly spaces the end of the message from the first diff, and
leaving another empty line at the end looks ugly.
Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Paul Mackerras <paulus@samba.org>
gitk: Refactor per-line part of getblobdiffline and its support
For later use with data sources other than a pipe, refactor the big
worker part of getblobdiffline to a separate function
parseblobdiffline. Also refactor its initialization and wrap-up to
separate routines.
Signed-off-by: Thomas Rast <trast@inf.ethz.ch> Signed-off-by: Paul Mackerras <paulus@samba.org>
git-cherry(1)'s "description" section has never really managed
to explain to me what the command does. It contains too much
explanation of the algorithm instead of simply saying what
goals it achieves, and too much terminology that we otherwise
do not use (fork-point instead of merge-base).
Try a much more concise approach: state what it finds out, why
this is neat, and how the output is formatted, in a few short
paragraphs. In return, provide much longer examples of how it
fits into a "format-patch | am" based workflow, and how it
compares to reading the same from git-log.
Also carefully avoid using "merge" in a context where it does
not mean something that comes from git-merge(1). Instead, say
"apply" in an attempt to further link to patch workflow
concepts.
While there, also omit the language about _which_ upstream
branch we treat as the default. I literally just learned that
we support having several, so let's not confuse new users
here, especially considering that git-config(1) does not
document this.
Prompted-by: a.huemer@commend.com on #git Signed-off-by: Thomas Rast <tr@thomasrast.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
remote-hg: don't decode UTF-8 paths into Unicode objects
The internal mercurial API expects ordinary 8-bit string objects, not
Unicode string objects. With this change, the test-hg.sh unit tests
pass again.
Signed-off-by: Richard Hansen <rhansen@bbn.com> Reviewed-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This shuts up compiler warnings about unused functions. No such
warnings are currently triggered, but if someone were to actually
use init_NAME_with_stride() as documented, they would get a warning
about init_NAME() being unused.
While there, write a comment about why the last real declaration of
the variable is without a terminating semicolon, while another
forward declarations have one.
Signed-off-by: Thomas Rast <tr@thomasrast.ch> Helped-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In a shell snippet meant to be sourced by other shell scripts, an
opening #! line does more harm than good.
The harm:
- When the shell library is sourced, the interpreter and options from
the #! line are not used. Specifying a particular shell can
confuse the reader into thinking it is safe for the shell library
to rely on idiosyncrasies of that shell.
- Using #! instead of a plain comment drops a helpful visual clue
that this is a shell library and not a self-contained script.
- Tools such as lintian can use a #! line to tell when an
installation script has failed by forgetting to set a script
executable. This check does not work if shell libraries also start
with a #! line.
The good:
- Text editors notice the #! line and use it for syntax highlighting
if you try to edit the installed scripts (without ".sh" suffix) in
place.
The use of the #! for file type detection is not needed because Git's
shell libraries are meant to be edited in source form (with ".sh"
suffix). Replace the opening #! lines with comments.
This involves tweaking the test harness's valgrind support to find
shell libraries by looking for "# " in the first line instead of "#!"
(see v1.7.6-rc3~7, 2011-06-17).
Suggested by Russ Allbery through lintian. Thanks to Jeff King and
Clemens Buchacher for further analysis.
Tested by searching for non-executable scripts with #! line:
find . -name .git -prune -o -type f -not -executable |
while read file
do
read line <"$file"
case $line in
'#!'*)
echo "$file"
;;
esac
done
The only remaining scripts found are templates for shell scripts
(unimplemented.sh, wrap-for-bin.sh) and sample input used in tests
(t/t4034/perl/{pre,post}).
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
test: replace shebangs with descriptions in shell libraries
A #! line in these files is misleading, since these scriptlets are
meant to be sourced with '.' (using whatever shell sources them)
instead of run directly using the interpreter named on the #! line.
Removing the #! line shouldn't hurt syntax highlighting since
these files have filenames ending with '.sh'. For documentation,
add a brief description of how the files are meant to be used in
place of the shebang line.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This way, test authors don't need to remember to source
lib-prereq-FILEMODE.sh before using the FILEMODE prereq to guard tests
that rely on the executable bit being honored when checking out files.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The git p4import documentation has suggested git p4 as a better
alternative for more than 6 years. (According to the mailing list
discussion when it was moved to contrib/, git-p4import has serious
bugs --- e.g., its incremental mode just doesn't work.) Since then,
git p4 has been actively developed and was promoted to a standard git
command alongside git svn.
Searches on google.com/trends and stackoverflow suggest that no one is
looking for git-p4import any more. Remove it.
Noticed while considering marking the contrib/p4import/git-p4import.py
script executable as part of a wider sweep.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Acked-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The docs in contrib/hooks/pre-auto-gc-battery suggest:
For example, if the hook is stored in
/usr/share/git-core/contrib/hooks/pre-auto-gc-battery:
chmod a+x pre-auto-gc-battery
cd /path/to/your/repository.git
ln -sf /usr/share/git-core/contrib/hooks/pre-auto-gc-battery \
hooks/pre-auto-gc
Unfortunately on multi-user systems most users do not have write
access to /usr. Better to mark the sample hooks executable in
the first place so users do not have to tweak their permissions to
use them by symlinking into .git/hooks/.
Reported-by: Olivier Berger <olivier.berger@it-sudparis.eu> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
These scripts are not run directly as part of a normal build, so no
one noticed that they did not have the +x bit. Mark them executable
to make it more obvious that they can be run directly (when debugging,
for example).
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
On Windows the convention is to rely on filename extensions to decide
whether a file is executable so Windows users are probably not relying
on the executable bit of these scripts, but on other platforms it can
be useful documentation.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The output of git format-patch can vary with user preferences. In
particular setting diff.noprefix will break the "git apply" that
is done as part of "git p4 submit".
Acked-by: Pete Wyckoff <pw@padd.com> Signed-off-by: Crestez Dan Leonard <cdleonard@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In git v1.4.3, we introduced a new loose object format that
encoded some object information outside of the zlib stream.
Ultimately the format was dropped in v1.5.3, but we kept the
reading side around to help people migrate objects. Each
time we open a loose object, we use a heuristic to check
whether it is in the normal loose format, or the
experimental one.
This heuristic is robust in the face of valid data, but it
tends to treat corrupted or garbage data as an experimental
object. With the regular format, we would notice quickly
that zlib's crc does not check out and complain. With the
experimental object, we are likely to extract a nonsensical
object size and try to allocate a huge buffer, resulting in
xmalloc calling "die".
This latter behavior is much worse, for two reasons. One,
git reports an allocation error when the real error is
corruption. And two, the program dies unconditionally, so
you cannot even run fsck (which would otherwise ignore the
broken object and keep going).
We could try to improve the heuristic to err on the side of
normal objects in the face of corruption, but there is
really little point. The experimental format is long-dead,
and was never enabled by default to begin with. We can
instead simply remove it. The only affected repository would
be one that explicitly set core.legacyheaders in 2007, and
then never repacked in the intervening 6 years.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff: restrict pathspec limitations to diff b/f case only
builtin_diff_b_f() needs a path, not pathspec. Other modes in diff
can deal with pathspec just fine. But because of the current
GUARD_PATHSPEC() location, other modes also reject :(glob) and
:(icase).
Move GUARD_PATHSPEC(), and the "path" assignment statement, which is
the reason of this GUARD_PATHSPEC(), inside builtin_diff_b_f().
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce %(upstream:track) to display "[ahead M, behind N]" and
%(upstream:trackshort) to display "=", ">", "<", or "<>"
appropriately (inspired by contrib/completion/git-prompt.sh).
Now you can use the following format in for-each-ref:
%(refname:short)%(upstream:trackshort)
to display refs with terse tracking information.
Note that :track and :trackshort only work with "upstream", and error
out when used with anything else.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Makefile: add PERLLIB_EXTRA variable that adds to default perl path
Some platforms ship Perl modules used by git scripts outside the
default perl path (e.g., on Mac OS X, Subversion's perl bindings live
in a separate xcode perl path). Add an PERLLIB_EXTRA variable to hold
a colon-separated list of extra directories to add to the perl path in
git's scripts, as a convenience for packagers.
Requested-by: Dave Borowitz <dborowitz@google.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
'git branch' shows which branch you are currently on with an '*', but
'git for-each-ref' misses this feature. So, extend its format with
%(HEAD) for the same effect.
Now you can use the following format in for-each-ref:
%(HEAD) %(refname:short)
to display an asterisk next to the current ref.
Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Before, strings like "foo.bar@example.com" would be converted to
"foo. <bar@example.com>" when they should be "unknown
<foo.bar@example.com>".
Signed-off-by: Richard Hansen <rhansen@bbn.com> Reviewed-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
test-hg.sh: help user correlate verbose output with email test
It's hard to tell which author conversion test failed when the email
addresses look similar.
Signed-off-by: Richard Hansen <rhansen@bbn.com> Reviewed-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
test-hg.sh: fix duplicate content strings in author tests
"beta" was used twice. Change the second copy to "gamma" and
increment the remaining content strings.
Signed-off-by: Richard Hansen <rhansen@bbn.com> Reviewed-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The POSIX spec says that the '-a', '-o', and parentheses operands to
the 'test' utility are obsolete extensions due to the potential for
ambiguity. Replace '-o' with '|| test' to avoid unspecified behavior.
Signed-off-by: Richard Hansen <rhansen@bbn.com> Reviewed-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Unlike bash, POSIX shell does not specify a 'local' command for
declaring function-local variable scope. Except for IFS, the variable
names are not used anywhere else in the script so simply remove the
'local'. For IFS, move the assignment to the 'read' command to
prevent it from affecting code outside the function.
Signed-off-by: Richard Hansen <rhansen@bbn.com> Reviewed-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
test-bzr.sh, test-hg.sh: prepare for change to push.default=simple
Change 'git push <remote>' to 'git push <remote> <branch>' in one of
the test-bzr.sh tests to ensure that the test continues to pass when
the default value of push.default changes to simple.
Signed-off-by: Richard Hansen <rhansen@bbn.com> Reviewed-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
test-bzr.sh, test-hg.sh: allow running from any dir
Set TEST_DIRECTORY to the t/ directory (if TEST_DIRECTORY is not
already set) so that the user doesn't already have to be in the test
directory to run these test scripts.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Based-on-patch-by: Richard Hansen <rhansen@bbn.com> Reviewed-by: Richard Hansen <rhansen@bbn.com> Signed-off-by: Richard Hansen <rhansen@bbn.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
remote-hg: don't decode UTF-8 paths into Unicode objects
The internal mercurial API expects ordinary 8-bit string objects, not
Unicode string objects. With this change, the test-hg.sh unit tests
pass again.
Signed-off-by: Richard Hansen <rhansen@bbn.com> Reviewed-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
test-lib.sh: convert $TEST_DIRECTORY to an absolute path
If $TEST_DIRECTORY is specified in the environment, convert the value
to an absolute path to ensure that it remains valid even when 'cd' is
used.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Reviewed-by: Richard Hansen <rhansen@bbn.com> Signed-off-by: Richard Hansen <rhansen@bbn.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>