If we have both a tag and a branch named "foo", then calling
"git merge foo" will warn about the ambiguous ref, but merge
the tag.
When generating the commit message, though, we simply
checked whether "refs/heads/foo" existed, and if it did,
assumed it was a branch. This led to the statement "Merge
branch 'foo'" in the commit message, which is quite wrong.
Instead, we should use dwim_ref to find the actual ref used,
and describe it appropriately.
In addition to the test in t7608, we must also tweak the
expected output of t4202, which was accidentally triggering
this bug.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When calling "git merge $X", we automatically generate a
commit message containing something like "Merge branch
'$X'". This test script checks that those messages say what
they should, and exposes a failure when merging a refname
that is ambiguous between a tag and a branch.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When making a histogram of delta chain length in the pack, the program
collects number of objects whose delta depth exceeds the MAX_CHAIN limit
in histogram[0], and showed it as the number of items that exceeds the
limit correctly. HOWEVER, it also showed the same number labeled as
"chain length = 0".
In fact, we are not showing the number of objects whose chain length is
zero, i.e. the base objects. Correct this.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test ignored the exit status from verify pack command, and also relied
on not seeing any delta chain statistics.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The option --merge was missing for submodule update and --cached for
submodule summary.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Importing the popen2 module in Python-2.6 results in the
"DeprecationWarning: The popen2 module is deprecated. Use the
subprocess module." message. The module itself isn't used in fact, so
just removing it solves the problem.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Configuration values are expected to be quoted when they have leading or
trailing whitespace, but inner whitespace should be kept verbatim even if
the value is not quoted. This is already documented in git-config(1), but
the code caused inner whitespace to be collapsed to a single space,
breaking, for example, clones from a path that has two consecutive spaces
in it, as future fetches would only see a single space.
Reported-by: John te Bokkel <tanj.tanj@gmail.com>
Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use the description of "--ignore-errors" from git-add.txt as
inspiration.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The location to pull from should be converted from the configured nickname
to URL in the message, but ls-remote should be fed the nickname so that
the command uses remote.$nickname.* variables, most notably "uploadpack".
Signed-off-by: Tom Grennan <tgrennan@redback.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This includes mentioning the initial hash output of diff-tree, and
changes the header to "raw output format" which is more descriptive.
Signed-off-by: David Kågedal <davidk@lysator.liu.se>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use the less ambiguous
"set variable foo in order to enable bar"
rather than
"set variable foo to enable bar" which may trick users into
assuming that "enable" is a good value for "foo".
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git svn gc" will not compress unhandled.log files if
Compress::Zlib is missing. However, leftover index files should
always be removed, so add a test for this behavior as well.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Bodo Schlecht noticed that Instaweb didn't propely quote all
path instances in the Apache config file it generated.
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* en/fast-export:
fast-export: Document the fact that git-rev-list arguments are accepted
Add new fast-export testcases
fast-export: Add a --tag-of-filtered-object option for newly dangling tags
fast-export: Do parent rewriting to avoid dropping relevant commits
fast-export: Make sure we show actual ref names instead of "(null)"
fast-export: Omit tags that tag trees
fast-export: Set revs.topo_order before calling setup_revisions
* git://git.bogomips.org/git-svn:
git svn: make minimize URL more reliable over http(s)
git svn: avoid escaping '/' when renaming/copying files
t9142: stop httpd after the test
git svn: the branch command no longer needs the full path
git svn: revert default behavior for --minimize-url
git svn: add gc command
In addition to path-based restrictions, Subversion servers over
http(s) may have access controls implemented via the LimitExcept
directive in Apache. In some cases, LimitExcept may be
(arguably) misconfigured to not allow REPORT requests while
allowing OPTIONS and PROPFIND.
This caused problems with our existing minimize_url logic that
only issued OPTIONS and PROPFIND requests when connecting and
using SVN::Ra::get_latest_revnum. We now call SVN::Ra::get_log
if get_latest_revnum succeeds, resulting in a REPORT request
being sent. This will increase our chances of tripping access
controls before we start attempting to fetch history.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
asciidoc 8.4.1 changed the semantics of inline backtick quoting so
that they disable parsing of inline constructs, i.e.,
Input: `{plus}`
Pre 8.4.1: +
Post 8.4.1: {plus}
Fix this by defining the asciidoc attribute 'no-inline-literal'
(which, per the 8.4.1 changelog, is the toggle to return to the old
behaviour) when under ASCIIDOC8.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Timothy Schaeffer reported the following:
> Git-svn has been giving me the following error for some time
> when calling "git svn dcommit":
>
> RA layer request failed: PROPFIND request failed on
> '/svn/stf/branches/dev/sw%2Fdpemu%2Finclude%2FNetCnxn.h': PROPFIND of
> '/svn/stf/branches/dev/sw%2Fdpemu%2Finclude%2FNetCnxn.h': 302 Found
> (https://oursvnrepo.net) at /usr/local/libexec/git-core/git-svn line 508
>
> This only occurred when git detected a rename or copy.
>
> Following the lead into git-svn.perl,
> and noticing that some of the '/'s in the path were hex-encoded
> and some were not,
> I changed the regex used to find chars
> to hex-encode in the relative part of the path
> to exclude '/'.
> It works, so far.
> I have included a patch.
While this has previous not been a problem in my experience,
newer versions of SVN may be stricter and this does not
introduce regressions in t9115.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This was introduced in 0b2af457a4
("Fix branch detection when repository root is inaccessible")
but reintroduced in the previous commit.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This reverts the --minimize-url behavior change that
appeared recently in commit 0b2af457a4
("Fix branch detection when repository root is inaccessible").
However, we now allow the option to be turned off by allowing
"--no-minimize-url" so people with limited-access setups can
still take advantage of the fix in
0b2af457a4.
Also document the behavior and default settings of minimize-url
in the manpage for the first time.
This introduces a temporary UI regression to allow t9141 to pass
that will be reverted (fixed) in the next commit.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Add a git svn gc command that gzips all unhandled.log files, and
removes all index files under .git/svn.
Signed-off-by: Robert Allan Zeh <robert.a.zeh@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
The second and third tests of this script expected that Russian strings
are converted between ISO-8859-5 and Shift_JIS in the "blame --porcelain"
format output correctly.
Sure, many platforms may convert between such a combination, but that is
only because one of the base character set of Shift_JIS, JIS X 0208,
defines codepoints for Russian characters (among others); I do not think
anybody uses Shift_JIS when seriously writing Russian, and it is perfectly
understandable if iconv() libraries on some platforms fail converting
between this combination, as it does not matter in reality.
This patch changes the test to verify Japanese strings are converted
correctly between EUC-JP and Shift_JIS in the same procedure. The point
of the test is not about verifying the platform's iconv() library, but to
see if "git blame" makes correct iconv() library calls when it should.
We could instead use ISO-8859-5 and KOI8-R as the combination, because
they are both meant to represent Russian, in order to make this test
meaningful on more platforms, but we already use Shift_JIS vs EUC-JP
combinations to test other programs in our test suite, so this combination
is safer from the point of view of the portability. Besides, I do not
read nor write Russian; sorry ;-)
This change allows tests to pass on my (friend's) Solaris 5.11 box.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
735c674 (Trailing whitespace and no newline fix, 2009-07-22) completely
broke --whitespace=fix, causing it to lose all the empty lines in a patch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* js/maint-graft-unhide-true-parents:
git repack: keep commits hidden by a graft
Add a test showing that 'git repack' throws away grafted-away parents
Conflicts:
git-repack.sh
* av/maint-config-reader:
After renaming a section, print any trailing variable definitions
Make section_name_match start on '[', and return the length on success
With the previous code, an alias cycle like:
$ echo 'alias a b' >aliases
$ echo 'alias b a' >aliases
$ git config sendemail.aliasesfile aliases
$ git config sendemail.aliasfiletype mutt
would put send-email into an infinite loop. This patch
detects the situation and complains to the user.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Added the envvar GIT_PS1_SHOWUNTRACKEDFILES to 'git-completion.bash'.
When set to a nonempty value, then the char '%' will be shown next
to the branch name in the bash prompt.
Signed-off-by: Daniel Trstenjak <daniel.trstenjak@science-computing.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
SunOS grep does not understand -C<n> nor -e
Fix export_marks() error handling.
git branch: clean up detached branch handling
git branch: avoid unnecessary object lookups
git branch: fix performance problem
do_one_ref(): null_sha1 check is not about broken ref
Conflicts:
Makefile
The first "grep -C1" test in t7002 does not pass on my SunOS-5.11-i86pc,
and that is not because our way to spawn external grep is broken, but
because the native grep does not understand -C<n>.
It turns out that Peff was also using this option himself because our
Makefile doesn't do that automatically. Brandon Casey uses SUNWspro
compiler without having to set this, and it turns out that the compiler
does not define preprocessor macro __unix__ which made him always use the
built-in grep, never an external one.
Let's be more explicit and say that we do not use external grep on Suns.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King