When rev-parse looks at whether an argument like "foo..bar" or
"foobar^@" is a difference or parent-shorthand, it internally
munges the arguments so that it can pass the individual rev
arguments to get_sha1(). However, we do not consistently un-munge
the result.
For cases where we do not match (e.g., "doesnotexist..HEAD"), we
would then want to try to treat the argument as a filename.
try_difference gets() this right, and always unmunges in this case.
However, try_parent_shorthand() never unmunges, leading to incorrect
error messages, or even incorrect results:
$ git rev-parse foobar^@
foobar
fatal: ambiguous argument 'foobar': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
$ >foobar
$ git rev-parse foobar^@
foobar
For cases where we do match, neither function unmunges. This does
not currently matter, since we are done with the argument. However,
a future patch will do further processing, and this prepares for
it. In addition, it's simply a confusing interface for some cases to
modify the const argument, and others not to.
Signed-off-by: Jeff King <peff@peff.net>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Rev-parse understands that a "--" may separate revisions and
filenames, and that anything after the "--" is taken as-is.
However, it does not understand that anything before the
token must be a revision (which is the usual rule
implemented by the setup_revisions parser).
Since rev-parse prefers revisions to files when parsing
before the "--", we end up with the correct result (if such
an argument is a revision, we parse it as one, and if it is
not, it is an error either way). However, we misdiagnose
the errors:
$ git rev-parse foobar -- >/dev/null
fatal: ambiguous argument 'foobar': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'
$ >foobar
$ git rev-parse foobar -- >/dev/null
fatal: bad flag '--' used after filename
In both cases, we should know that the real error is that
"foobar" is meant to be a revision, but could not be
resolved.
Signed-off-by: Jeff King <peff@peff.net>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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>
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>
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>
Unbreaks a recent breakage due to use of unquote-c-style.
This may need to be cherry-picked down to 1.8.4.x series.
* 'rh/remote-hg-bzr-updates' (early part):
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>
Hotfix for recent regression while talking to upload-pack
in a repository with many symbolic refs.
* maint:
Revert "upload-pack: send non-HEAD symbolic refs"
Commit f2e0873 (branch: report invalid tracking branch as gone) removed
an early return from fill_tracking_info() in the path taken when 'git
branch -v' lists a branch in sync with its upstream. This resulted in an
unconditionally added space in front of the subject line:
$ git branch -v
* master f5eb3da commit pushed to upstream
topic f935eb6 unpublished topic
Instead, only add the trailing space if a decoration have been added.
To catch this kind of whitespace breakage in the tests, be a bit less
smart when filtering the output through sed.
Signed-off-by: Torstein Hegge <hegge@resisty.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This reverts commit 5e7dcad771cb873e278a0571b46910d7c32e2f6c; there
may be unbounded number of symbolic refs in the repository, but the
capability header line in the on-wire protocol has a rather low
length limit.
"timezone" is two words, not one (i.e. "time zone" is correct).
Correct this in these files:
-- date-formats.txt
-- git-blame.txt
-- git-cvsimport.txt
-- git-fast-import.txt
-- git-svn.txt
-- gitweb.conf.txt
-- rev-list-options.txt
Signed-off-by: Jason St. John <jstjohn@purdue.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Translate 68 new messages came from git.pot update in 727b957
(l10n: git.pot: v1.8.5 round 1 (68 new, 9 removed)).
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
Acked-by: Thomas Rast <tr@thomasrast.ch>
The interaction between use of Perl in our test suite and NO_PERL
has been clarified a bit.
* jn/test-prereq-perl-doc:
t/README: tests can use perl even with NO_PERL
A fast-import stream expresses a pathname with funny characters by
quoting them in C style; remote-hg remote helper (in contrib/)
forgot to unquote such a path.
* ap/remote-hg-unquote-cquote:
remote-hg: unquote C-style paths when exporting
One long-standing flaw in the pack transfer protocol used by "git
clone" was that there was no way to tell the other end which branch
"HEAD" points at, and the receiving end needed to guess. A new
capability has been defined in the pack protocol to convey this
information so that cloning from a repository with more than one
branches pointing at the same commit where the HEAD is at now
reliably sets the initial branch in the resulting repository.
* jc/upload-pack-send-symref:
t5570: Update for clone-progress-to-stderr branch
t5570: Update for symref capability
clone: test the new HEAD detection logic
connect: annotate refs with their symref information in get_remote_head()
connect.c: make parse_feature_value() static
upload-pack: send non-HEAD symbolic refs
upload-pack: send symbolic ref information as capability
upload-pack.c: do not pass confusing cb_data to mark_our_ref()
t5505: fix "set-head --auto with ambiguous HEAD" test
We did not handle cases where http transport gets redirected during
the authorization request (e.g. from http:// to https://).
* jk/http-auth-redirects:
http.c: Spell the null pointer as NULL
remote-curl: rewrite base url from info/refs redirects
remote-curl: store url as a strbuf
remote-curl: make refs_url a strbuf
http: update base URLs when we see redirects
http: provide effective url to callers
http: hoist credential request out of handle_curl_result
http: refactor options to http_get_*
http_request: factor out curlinfo_strbuf
http_get_file: style fixes
An ancient How-To on serving Git repositories on an HTTP server
lacked a warning that it has been mostly superseded with more
modern way.
* sc/doc-howto-dumb-http:
doc/howto: warn about (dumb)http server document being too old
The synopsis section of "git unpack-objects" documentation has been
clarified a bit.
* vd/doc-unpack-objects:
Documentation: "pack-file" is not literal in unpack-objects
Documentation: restore a space in unpack-objects usage
"git checkout topic", when there is not yet a local "topic" branch
but there is a unique remote-tracking branch for a remote "topic"
branch, pretended as if "git checkout -t -b topic remote/$r/topic"
(for that unique remote $r) was run. This hack however was not
implemented for "git checkout topic --".
* mm/checkout-auto-track-fix:
checkout: proper error message on 'git checkout foo bar --'
checkout: allow dwim for branch creation for "git checkout $branch --"
Bash prompting code to deal with an SVN remote as an upstream
were coded in a way not supported by older Bash versions (3.x).
* sg/prompt-svn-remote-fix:
bash prompt: don't use '+=' operator in show upstream code path
The fall-back parsing of commit objects with broken author or
committer lines were less robust than ideal in picking up the
timestamps.
* jk/split-broken-ident:
split_ident: parse timestamp from end of line
"git rev-list --objects ^v1.0^ v1.0" gave v1.0 tag itself in the
output, but "git rev-list --objects v1.0^..v1.0" did not.
* jc/revision-range-unpeel:
revision: do not peel tags used in range notation
