Junio C Hamano [Wed, 22 Aug 2012 18:51:20 +0000 (11:51 -0700)]
Merge branch 'ms/git-svn-1.7'
A series by Michael Schwern via Eric to update git-svn to revamp the
way URLs are internally passed around, to make it work with SVN 1.7.
* ms/git-svn-1.7:
git-svn: remove ad-hoc canonicalizations
git-svn: canonicalize newly-minted URLs
git-svn: introduce add_path_to_url function
git-svn: canonicalize earlier
git-svn: replace URL escapes with canonicalization
git-svn: attempt to mimic SVN 1.7 URL canonicalization
t9107: fix typo
t9118: workaround inconsistency between SVN versions
Git::SVN{,::Ra}: canonicalize earlier
git-svn: path canonicalization uses SVN API
Git::SVN::Utils: remove irrelevant comment
git-svn: add join_paths() to safely concatenate paths
git-svn: factor out _collapse_dotdot function
git-svn: use SVN 1.7 to canonicalize when possible
git-svn: move canonicalization to Git::SVN::Utils
use Git::SVN{,::RA}->url accessor globally
use Git::SVN->path accessor globally
Git::SVN::Ra: use accessor for URLs
Git::SVN: use accessor for URLs internally
Git::SVN: use accessors internally for path
Besides reusing the new test prerequisite, this fixes also the issue
that the current output is not TAP compliant and produces the output "no
reason given" [for skipping].
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Eric S. Raymond [Wed, 22 Aug 2012 10:52:30 +0000 (06:52 -0400)]
contrib/ciabot: Get ciabot configuration from git variables
These changes remove all need to modify the ciabot scripts for installation.
Instead, per-project configuration can be dome via variables in a [ciabot]
section of the config file.
Also, correct for the new server address.
Signed-off-by: Eric S. Raymond <esr@thyrsus.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Linus Torvalds [Thu, 28 Jun 2012 18:24:14 +0000 (11:24 -0700)]
commit/commit-tree: correct latin1 to utf-8
When a line in the message is not a valid utf-8, "git mailinfo"
attempts to convert it to utf-8 assuming the input is latin1 (and
punt if it does not convert cleanly). Using the same heuristics in
"git commit" and "git commit-tree" lets the editor output be in
latin1 to make the overall system more consistent.
Junio C Hamano [Tue, 21 Aug 2012 21:52:07 +0000 (14:52 -0700)]
warn_on_inaccessible(): a helper to warn on inaccessible paths
The previous series introduced warnings to multiple places, but it
could become tiring to see the warning on the same path over and
over again during a single run of Git. Making just one function
responsible for issuing this warning, we could later choose to keep
track of which paths we issued a warning (it would involve a hash
table of paths after running them through real_path() or something)
in order to reduce noise.
Right now we do not know if the noise reduction is necessary, but it
still would be a good code reduction/sharing anyway.
Jeff King [Tue, 21 Aug 2012 06:31:52 +0000 (02:31 -0400)]
attr: warn on inaccessible attribute files
Just like config and gitignore files, we silently ignore
missing or inaccessible attribute files. An existent but
inaccessible file is probably a configuration error, so
let's warn the user.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Tue, 21 Aug 2012 06:26:07 +0000 (02:26 -0400)]
gitignore: report access errors of exclude files
When we try to access gitignore files, we check for their
existence with a call to "access". We silently ignore
missing files. However, if a file is not readable, this may
be a configuration error; let's warn the user.
For $GIT_DIR/info/excludes or core.excludesfile, we can just
use access_or_warn. However, for per-directory files we
actually try to open them, so we must add a custom warning.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jeff King [Tue, 21 Aug 2012 06:10:59 +0000 (02:10 -0400)]
config: warn on inaccessible files
Before reading a config file, we check "!access(path, R_OK)"
to make sure that the file exists and is readable. If it's
not, then we silently ignore it.
For the case of ENOENT, this is fine, as the presence of the
file is optional. For other cases, though, it may indicate a
configuration error (e.g., not having permissions to read
the file). Let's print a warning in these cases to let the
user know.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Kacper Kornet [Tue, 21 Aug 2012 07:47:26 +0000 (09:47 +0200)]
for-each-ref: Fix sort with multiple keys
The linked list describing sort options was not correctly set up in
opt_parse_sort. In the result, contrary to the documentation, only the
last of multiple --sort options to git-for-each-ref was taken into
account. This commit fixes it.
Signed-off-by: Kacper Kornet <draenog@pld-linux.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Kacper Kornet [Tue, 21 Aug 2012 07:46:06 +0000 (09:46 +0200)]
t6300: test sort with multiple keys
Documentation of git-for-each-ref says that --sort=<key> option can be
used multiple times, in which case the last key becomes the primary key.
However this functionality was never checked in test suite and is
currently broken. This commit adds appropriate test in preparation for fix.
Signed-off-by: Kacper Kornet <draenog@pld-linux.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Thomas Rast [Mon, 20 Aug 2012 18:24:56 +0000 (20:24 +0200)]
gettext: do not translate empty string
The gettext .po files have a header, but it looks like the
translation specification for an empty string. This results in
_("") actually returning that header.
Check the input to _() and do not call gettext() on an empty string;
in some places, we run _(opts->help) where opts->help may be empty.
Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Pete Wyckoff [Sat, 11 Aug 2012 16:55:04 +0000 (12:55 -0400)]
git p4: make branch detection work with --use-client-spec
The bug report in http://stackoverflow.com/questions/11893688
observes that files are mapped into the wrong locations in
git when both --use-client-spec and --branch-detection are enabled.
Fix this by changing the relative path prefix to match discovered
branches when using a client spec.
The problem was likely introduced with ecb7cf9 (git-p4: rewrite view
handling, 2012-01-02).
Signed-off-by: Pete Wyckoff <pw@padd.com> Tested-by: Matthew Korich <matthew@korich.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano [Sat, 18 Aug 2012 23:35:09 +0000 (16:35 -0700)]
git-config doc: unconfuse an example
One fictitious command "proxy-command" is enclosed inside a double
quote pair, while another fictitious command "default-proxy" is not
in the example, but the quoting does not change anything in the pair
of examples. Remove the quotes to avoid unnecessary confusion.
Junio C Hamano [Fri, 17 Aug 2012 19:48:52 +0000 (12:48 -0700)]
Documentation: update the introductory section
The second paragraph in the git(1) description section were meant to
guide people who are not ready to dive into this page away from here.
Referring migrating CVS users to another page before they get
acquainted with Git was somewhat out of place. Move the reference to
the "FURTHER DOCUMENTATION" section and push that section down.
Phil Hord [Tue, 10 Jul 2012 22:52:28 +0000 (18:52 -0400)]
stash: invoke rerere in case of conflict
"stash apply" directly calls a backend merge function which does not
automatically invoke rerere. This confuses mergetool when leftover
rerere state is left behind from previous merges.
Invoke rerere explicitly when we encounter a conflict during stash
apply. This turns the test introduced by the previous commit to
succeed.
Signed-off-by: Phil Hord <hordp@cisco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Phil Hord [Tue, 10 Jul 2012 22:52:27 +0000 (18:52 -0400)]
test: git-stash conflict sets up rerere
Add a test to make sure that a conflicted "stash apply" invokes
rerere to record the conflicts and resolve the the files it can
(the current code doesn't, so the test is marked as failing).
Without correct state recorded for rerere, mergetool may be
confused, causing it to think no files have conflicts even though
they do. This condition is not verified by this test since a
subsequent commit will change the behavior to enable rerere for
stash conflicts.
Also, the next test expected us to finish up with a reset, which is
impossible to do if we fail (as we must) and it's an unreasonable
expectation anyway. Begin the next test with a reset of its own
instead.
Signed-off-by: Phil Hord <hordp@cisco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Miklos Vajna [Thu, 16 Aug 2012 09:50:18 +0000 (11:50 +0200)]
man: git pull -r is a short for --rebase
Letting the "--rebase" option squat on the short-and-sweet single
letter option "-r" was an unintended accident and was not even
documented, but the short option seems to be already used in the
wild. Let's document it so that other options that begin with "r"
would not be tempted to steal it.
Signed-off-by: Miklos Vajna <vmiklos@suse.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
projects / rit / log