As we know a caller that does not recurse is calling us in the index
order, we can remember the last directory we found to be excluded
and see if the path we are looking at is still inside it, in which
case we can just answer that it is excluded.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git ls-files --exclude=t/ -i" does not show paths in directory t/
that have been added to the index, but it should.
The excluded() API was designed for callers who walk the tree from
the top, checking each level of the directory hierarchy as it
descends if it is excluded, and not even bothering to recurse into
an excluded directory. This would allow us optimize for a common
case by not having to check if the exclude pattern "foo/" matches
when looking at "foo/bar", because the caller should have noticed
that "foo" is excluded and did not even bother to read "foo/bar"
out of opendir()/readdir() to call it.
The code for "ls-files -i" however walks the index linearly, feeding
paths without checking if the leading directory is already excluded.
Introduce a helper function path_excluded() to let this caller
properly call excluded() check for higher hierarchies as necessary.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "git rebase" was given a bad commit to replay the history on,
its error message did not correctly give the command line argument
it had trouble parsing.
By Erik Faye-Lund
* ef/maint-rebase-error-message:
rebase: report invalid commit correctly
This means we will respect the GIT_USER_AGENT build-time
configuration and run-time environment variable.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is basically a fancy way of saying "git/$GIT_VERSION",
except that it is overridable at build-time and through the
environment. Which means that people who don't want to
advertise their git version (for privacy or security
reasons) can tweak it.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The global git_version_string currently lives in git.c, but
doesn't have anything to do with the git wrapper. Let's move
it into its own file, where it will be more appropriate to
build more version-related functions.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The translation of "builtin/gc.c:224" was missing of
a newline which made the second part of the message
quite long. We simply add a newline.
Signed-off-by: Ralf Thielow <ralf.thielow@googlemail.com>
Translate 2 new and 3 fuzzy messages came from git.pot update
in 75f7b4b (l10n: Update git.pot (5 new, 3 removed messages)).
Signed-off-by: Ralf Thielow <ralf.thielow@googlemail.com>
Translate 2 new and 3 fuzzy messages came from git.pot update
in 75f7b4b (l10n: Update git.pot (5 new, 3 removed messages)).
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
"git rebase -p" used to pay attention to rebase.autosquash which was
wrong. "git rebase -p -i" should, but "git rebase -p" by itself
should not.
By Vincent van Ravesteijn
* vr/rebase-autosquash-does-not-imply-i:
Do not autosquash in case of an implied interactive rebase
"git tags" used to suggest "git stage" which was nonsense; it should
have favored "git tag". Tweak the cost of deletion to correct it.
By Matthieu Moy
* mm/levenstein-penalize-deletion-less:
Reduce cost of deletion in levenstein distance (4 -> 3)
"git submodule init" used to report "registered for path ..." even
for submodules that were registered earlier.
By Jens Lehmann
* jl/submodule-report-new-path-once:
submodules: print "registered for path" message only once
By Jiang Xin (4) and others
via Jiang Xin
* git://github.com/git-l10n/git-po:
l10n: Set nplurals of zh_CN.po from 1 to 2
l10n: zh_CN.po: translate 323 new messages
l10n: zh.CN.po: update by msgmerge git.pot
First release translation for Vietnamese
Init translation for Vietnamese
l10n: New it.po file with 504 translations
Update Swedish translation (728t0f0u)
l10n: Update git.pot (41 new messages)
"git grep -e '$pattern'", unlike the case where the patterns are read from
a file, did not treat individual lines in the given pattern argument as
separate regular expressions as it should.
By René Scharfe
* rs/maint-grep-F:
grep: stop leaking line strings with -f
grep: support newline separated pattern list
grep: factor out do_append_grep_pat()
grep: factor out create_grep_pat()
An author/committer name that is a single character was mishandled as an
invalid name by mistake.
By Jeff King
* jk/ident-split-fix:
fix off-by-one error in split_ident_line
"git checkout" gave progress display even when the standard error
stream was not connected to the tty, which made little sense.
By Avery Pennarun
* ap/checkout-no-progress-for-non-tty:
checkout: no progress messages if !isatty(2).
After tagging the tip of "dev" branch with a "for-linus" tag and
pushing both out, running
$ git request-pull $url $last_release dev
would produce an output asking the 'dev' branch of $url to be
pulled, because that is what the user asked the message to say.
We already detect this situation locally and include the contents of
the tag in the output; if the $url has that tag, favor that tag
(i.e. "for-linus") in the generated message over the branch name the
user gave us (i.e. "dev") from the command line, to make the output
look more consistent.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The 4th arg of "new mode (%o) of %s does not match old mode (%o)%s%s"
is blank string or string " of ". Even mark the string " of " for a
complete i18n, this message is still hard to translate right.
Split it into two slight different messages would make l10n teams happy.
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In most cases, plural-forms are unnecessary for Chinese. For example,
"apple" and "apples" are the same in Chinese, they are both translated
as "苹果". While there are exceptions, e.g., the plural form of "he",
"she" and "it" is "they" in English. In Chinese, "他(he)", "她(she)",
and "它(it)" have plural forms too, they are "他们", "她们", and "它们".
But what makes 'nplurals=1' hard to work right for Chinese is:
#: bundle.c:192
#, c-format
msgid "The bundle requires this ref"
msgid_plural "The bundle requires these %d refs"
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Update Simplified Chinese translation for 134 fuzzy, 189 new messages
from Git v1.7.10.2-548-g9de96.
Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Signed-off-by: Zhuang Ya <zhuangya@me.com>
In 20fc9bc (Set HTTP user agent to git/GIT_VERSION, 2006-04-04),
http.o started recording GIT_VERSION, but http.o wasn't added
to the list of files that depends on GIT-VERSION-FILE.
Fix this, so mofications to GIT-VERSION-FILE will result in an
updated user-agent string.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Git over HTTPS has a high request startup latency, since the SSL
negotiation can take up to a second. In order to reduce this latency,
connections should be left open to the Git server across requests
(or invocations of the git commandline).
Reduce SSL startup latency by running a daemon job that keeps
connections open to a Git server. The daemon job
(git-remote-persistent-https--proxy) is started on the first request
through the client binary (git-remote-persistent-https) and remains
running for 24 hours after the last request, or until a new daemon
binary is placed in the PATH. The client determines the daemon's
HTTP address by communicating over a UNIX socket with the daemon.
From there, the rest of the Git protocol work is delegated to the
"git-remote-http" binary, with the environment's http_proxy set to
the daemon.
Accessing /pub/scm/linux/kernel/git/torvalds/linux repository hosted
at kernel.googlesource.com with "git ls-remote" over https:// and
persistent-https:// 5 times shows that the first request takes about
the same time (0.193s vs 0.208s---there is a slight set-up cost for
the local proxy); as expected, the other four requests are much
faster (~0.18s vs ~0.08s).
Incidentally, this also has the benefit of HTTP keep-alive working
across Git command invocations. Its common for servers to use a 5
minute keep-alive on an HTTP 1.1 connection. Git-over-HTTP commonly
uses Transfer-Encoding: chunked on replies, so keep-alive will
generally just work, even though a pack stream's length isn't known
in advance. Because the helper is an external process holding that
connection open, we also benefit from being able to reuse an
existing TCP connection to the server. The same "git ls-remote"
test against http:// vs persistent-https:// URL shows that the
former takes ~0.09s while the first request for the latter is about
0.134s with set-up cost, and subsequent requests are ~0.065s,
shaving around one RTT to the server.
Signed-off-by: Colby Ranger <cranger@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In 9765b6a (rebase: align variable content, 2011-02-06), the code
to error out was moved up one level. Unfortunately, one reference
to a function parameter wasn't rewritten as it should, leading to
the wrong parameter being errored on.
This error was propagated by 71786f5 (rebase: factor out reference
parsing, 2011-02-06) and merged in 78c6e0f (Merge branch
'mz/rebase', 2011-04-28).
Correct this by reporting $onto_name istead.
Reported-By: Manuela Hutter <manuelah@opera.com>
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is basically the same as using "file://", but is a
little less subtle for the end user. It also allows relative
paths to be specified.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The --local flag is not "treat this like a local
repository", but rather "if we are local, turn on
optimizations". Therefore it does nothing in the case of:
git clone --local file:///path/to/repo
Let's make that more clear in the documentation.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This comment warns about a bug in asciidoc 6, and points to
a patch from 2005. Since we don't even support versions of
asciidoc that old, we can safely get rid of the warning.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we made the switch to supporting asciidoc 8 in 4c7100a
(Documentation: adjust to AsciiDoc 8, 2007-06-14), we were
able to leave most of the documentation intact by defining
asciidoc7compatible.
Since commit 6cf378f (docs: stop using asciidoc no-inline-literal,
2012-04-26), we don't support versions of asciidoc older
than 8.4.1, which is when inline literals were introduced.
Therefore there is not much point in keeping our
documentation compatible with asciidoc 7.
So we are now free to drop the asciidoc7compatible flag and
update the documentation itself to assume asciidoc8.
Fortunately, doing the latter is very easy; we weren't using
any of the constructs impacted by asciidoc7compatible, so
there are no changes to make.
The reason is somewhat subtle. The asciidoc7compatible
affects only super/sub-scripts ("^" and "~") and index
terms. We don't use the latter at all. Nor we do we use the
former, but we did have to protect them from accidental
expansion in constructs like "rev^1". However, all of our
uses of "~" and "^" are either in code blocks (which are
rendered literally), or inside backticks. Prior to 6cf378f,
backticks were not inline literals, and needed proper
quoting. But post-6cf378f, we don't have to worry whether we
are using the old or new rules, as those characters are not
interpreted at all in either case.
I verified that the result of "make install-html
install-man" is identical before and after this patch on
asciidoc 8.6.7.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since commit 6cf378f (docs: stop using asciidoc no-inline-literal),
we no longer support asciidoc versions less than 8.4.1,
which introduced inline literals. Note this in the INSTALL
document.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The earlier "--keep-redundant-commit" series broke "cherry-pick"
that is given a commit whose change is already in the current
history. Such a cherry-pick would result in an empty change, and
should stop with an error, telling the user that conflict resolution
may have made the result empty (which is exactly what is happening),
but we silently dropped the change on the floor without any message
nor non-zero exit code.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since 2cd9de3e (submodule add: always initialize .git/config entry) the
message "Submodule '\$name' (\$url) registered for path '\$sm_path'" is
printed every time cmd_init() is called, e.g. each time "git submodule
update" is used with the --init option.
This was not intended and leads to bogus output which can confuse users
and build systems. Apart from that the $url variable was not set after the
first run which did the actual initialization and only "()" was printed
in subsequent runs where "($url)" was meant to inform the user about the
upstream repo.
Fix that by moving the say command in question into the if block where the
url is initialized, restoring the behavior that was in place before the
2cd9de3e commit. While at it also remove the comment which still describes
the logic used before 2cd9de3e and add a comment about how things work now.
Reported-by: Nicolas Viennot and Sid Nair <nicolas@viennot.com>
Reported-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
