Merge branch 'maint' of git://github.com/git-l10n/git-po into maint
By Ralf Thielow (6) and others
via Jiang Xin
* 'maint' of git://github.com/git-l10n/git-po:
l10n: zh_CN.po: translate 1 new message
l10n: de.po: translate one new message
l10n: de.po: unify translation of "ahead" and "behind"
l10n: de.po: collection of improvements
l10n: de.po: translate "remote" as "extern"
l10n: de.po: translate "track" as "beobachten"
l10n: add new members to German translation team
l10n: de.po: collection of suggestions
l10n: de.po: translate "bad" as "ungültig" ("invalid")
l10n: de.po: hopefully uncontroversial fixes
l10n: de.po: translate "bare" as "bloß"
l10n: Update git.pot (1 new messages)
Merge branch 'jk/maint-reflog-walk-count-vs-time' into maint
Gives a better DWIM behaviour for --pretty=format:%gd, "stash list", and
"log -g", depending on how the starting point ("master" vs "master@{0}" vs
"master@{now}") and date formatting options (e.g. "--date=iso") are given
on the command line.
By Jeff King (4) and Junio C Hamano (1)
* jk/maint-reflog-walk-count-vs-time:
reflog-walk: tell explicit --date=default from not having --date at all
reflog-walk: always make HEAD@{0} show indexed selectors
reflog-walk: clean up "flag" field of commit_reflog struct
log: respect date_mode_explicit with --format:%gd
t1411: add more selector index/date tests
By Jan Krüger (1) and Junio C Hamano (1)
* jk/maint-tformat-with-z:
log-tree: the previous one is still not quite right
log-tree: use custom line terminator in line termination mode
Merge branch 'js/checkout-detach-count' into maint
When checking out another commit from an already detached state, we used
to report all commits that are not reachable from any of the refs as
lossage, but some of them might be reachable from the new HEAD, and there
is no need to warn about them.
By Johannes Sixt
* js/checkout-detach-count:
checkout (detached): truncate list of orphaned commits at the new HEAD
t2020-checkout-detach: check for the number of orphaned commits
Merge branch 'ef/maint-clone-progress-fix' into maint
Some time ago, "git clone" lost the progress output for its "checkout"
phase; when run without any "--quiet" option, it should give progress to
the lengthy operation.
By Erik Faye-Lund
* ef/maint-clone-progress-fix:
clone: fix progress-regression
pack-protocol: fix first-want separator in the examples
When sending the "want" list, the capabilities list is separated from
the obj-id by a SP instead of NUL as in the ref advertisement. The
text is correct, but the examples wrongly show the separator as
NUL. Fix the example so it uses SP.
Signed-off-by: Carlos Martín Nieto <cmn@elego.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The cases "git push" fails due to non-ff can be broken into three
categories; each case is given a separate advise message.
By Christopher Tiwald (2) and Jeff King (1)
* ct/advise-push-default:
Fix httpd tests that broke when non-ff push advice changed
clean up struct ref's nonfastforward field
push: Provide situational hints for non-fast-forward errors
Merge branch 'jk/repack-no-explode-objects-from-old-pack' into maint
"git repack" used to write out unreachable objects as loose objects
when repacking, even if such loose objects will immediately pruned
due to its age.
By Jeff King
* jk/repack-no-explode-objects-from-old-pack:
gc: use argv-array for sub-commands
argv-array: add a new "pushl" method
argv-array: refactor empty_argv initialization
gc: do not explode objects which will be immediately pruned
document submdule.$name.update=none option for gitmodules
This option was not yet described in the gitmodules documentation. We
only described it in the 'git submodule' command documentation but
gitmodules is the more natural place to look.
A short reference in the 'git submodule' documentation should be
sufficient since the details can now be found in the documentation to
gitmodules.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git push" over smart-http lost progress output a few releases ago.
By Jeff King
* jk/maint-push-progress:
t5541: test more combinations of --progress
teach send-pack about --[no-]progress
send-pack: show progress when isatty(2)
"log --graph" was not very friendly with "--stat" option and its output
had line breaks at wrong places.
By Lucian Poston (5) and Zbigniew Jędrzejewski-Szmek (3)
* lp/diffstat-with-graph:
t4052: work around shells unable to set COLUMNS to 1
test-lib: skip test with COLUMNS=1 under mksh
Prevent graph_width of stat width from falling below min
t4052: Test diff-stat output with minimum columns
t4052: Adjust --graph --stat output for prefixes
Adjust stat width calculations to take --graph output into account
Add output_prefix_length to diff_options
t4052: test --stat output with --graph
In abe1998 ("git checkout -b: allow switching out of an unborn
branch"), a code-path overly-optimisticly assumed that a
branch-name was specified. This is not always the case, and as
a result a NULL-pointer was attempted printed to .git/HEAD.
This could lead to at least two different failure modes:
1) vsnprintf formated the NULL-string as something useful (e.g
"(null)")
2) vsnprintf crashed
Neither were very convenient for formatting a new HEAD-reference.
To fix this, reintroduce some strictness so we only take this
new codepath if a banch-name was specified.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Translate one new messages came from git.pot
update in 7795e42 (l10n: Update git.pot (1 new messages)).
It also updates and reformats the de.po file due to "msgmerge".
The word "remote" was translated as "entfernt"
and "anders". Both of them aren't really good
because "anders" in German means "other" and
"entfernt" has two different meanings and could
result in confusion to the users.
We've changed the translation to "extern".
Suggested-by: Jan Krüger <jk@jk.gs> Signed-off-by: Ralf Thielow <ralf.thielow@googlemail.com>
The word "track" was translated as "verfolgen"
and "folgen". We've decided to translate "track" in
the meaning of tracked files/content as "beobachten"
and in the remote-tracking sense as "folgen".
Suggested-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Ralf Thielow <ralf.thielow@googlemail.com>
Documentation/git-config: describe and clarify "--local <file>" option
Describe config file selection in git-config. While the usage message of
git-config shows --local, the documentation page did not contain anything
about that.
Signed-off-by: Florian Achleitner <florian.achleitner.2.6.31@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
reflog-walk: tell explicit --date=default from not having --date at all
Introduction of opt->date_mode_explicit was a step in the right direction,
but lost that crucial bit at the very end of the callchain, and the callee
could not tell an explicitly specified "I want *date* but in default format"
from the built-in default value passed when there was no --date specified.
Merge branch 'jk/maint-gitweb-test-use-sane-perl' into maint
When using a Perl script on a system where "perl" found on user's $PATH
could be ancient or otherwise broken, we allow builders to specify the
path to a good copy of Perl with $PERL_PATH. The gitweb test forgot to
use that Perl when running its test.
By Jeff King (1) and Zbigniew Jędrzejewski-Szmek (1)
* jk/maint-gitweb-test-use-sane-perl:
Consistently use perl from /usr/bin/ for scripts
t/gitweb-lib: use $PERL_PATH to run gitweb
Merge branch 'rt/cherry-revert-conflict-summary' into maint
In the older days, the header "Conflicts:" in "cherry-pick" and "merge"
was separated by a blank line from the list of paths that follow for
readability, but when "merge" was rewritten in C, we lost it by
mistake. Remove the newline from "cherry-pick" to make them match again.
By Ralf Thielow
* rt/cherry-revert-conflict-summary:
sequencer: remove additional blank line
In 5bd631b3 ("clone: support multiple levels of verbosity"), the
default behavior to show progress of the implicit checkout in
the clone-command regressed so that progress was only shown if
the verbose-option was specified.
Fix this by making option_verbosity == 0 output progress as well.
Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
But if the new commit is actually one from this list (6aa1af6 in this
example), then the list in the warning can be truncated at the new HEAD,
because history beginning at HEAD is not "left behind". This makes it so.
Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
reflog-walk: always make HEAD@{0} show indexed selectors
When we are showing reflog selectors during a walk, we infer
from context whether the user wanted to see the index in
each selector, or the reflog date. The current rules are:
1. if the user asked for an explicit date format in the
output, show the date
2. if the user asked for ref@{now}, show the date
3. if neither is true, show the index
However, if we see "ref@{0}", that should be a strong clue
that the user wants to see the counted version. In fact, it
should be much stronger than the date format in (1). The
user may have been setting the date format to use in another
part of the output (e.g., in --format="%gd (%ad)", they may
have wanted to influence the author date).
This patch flips the rules to:
1. if the user asked for ref@{0}, always show the index
2. if the user asked for ref@{now}, always show the date
3. otherwise, we have just "ref"; show them counted by
default, but respect the presence of "--date" as a clue
that the user wanted them date-based
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
reflog-walk: clean up "flag" field of commit_reflog struct
When we prepare to walk a reflog, we parse the specification
and pull some information from it, such as which reflog to
look in (e.g., HEAD), and where to start (e.g., HEAD@{10} or
HEAD@{yesterday}). The resulting struct has a "recno" field
to show where in the reflog we are starting. It also has a
"flag" field; if true, it means the recno field came from
parsing a date like HEAD@{yesterday}.
There are two problems with this:
1. "flag" is an absolutely terrible name, as it conveys
nothing about the meaning
2. you can tell "HEAD" from "HEAD@{yesterday}", but you
can't differentiate "HEAD" from "HEAD{0}"
This patch converts the flag into a tri-state (and gives it
a better name!).
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we show a reflog selector (e.g., via "git log -g"), we
perform some DWIM magic: while we normally show the entry's
index (e.g., HEAD@{1}), if the user has given us a date
with "--date", then we show a date-based select (e.g.,
HEAD@{yesterday}).
However, we don't want to trigger this magic if the
alternate date format we got was from the "log.date"
configuration; that is not sufficiently strong context for
us to invoke this particular magic. To fix this, commit f4ea32f (improve reflog date/number heuristic, 2009-09-24)
introduced a "date_mode_explicit" flag in rev_info. This
flag is set only when we see a "--date" option on the
command line, and we a vanilla date to the reflog code if
the date was not explicit.
Later, commit 8f8f547 (Introduce new pretty formats %g[sdD]
for reflog information, 2009-10-19) added another way to
show selectors, and it did not respect the date_mode_explicit
flag from f4ea32f.
This patch propagates the date_mode_explicit flag to the
pretty-print code, which can then use it to pass the
appropriate date field to the reflog code. This brings the
behavior of "%gd" in line with the other formats, and means
that its output is independent of any user configuration.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
We already check that @{now} and "--date" cause the
displayed selector to use the date for both the multiline
and oneline formats. However, we miss several cases:
1. The --format=%gd selector is not tested at all.
2. We do not check how the log.date config interacts with the
"--date" magic (according to f4ea32f, it should not
impact the output).
Doing so reveals that the combination of both (log.date
combined with the %gd format) does not behave as expected.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'jc/merge-reduce-parents-early' into maint
Octopus merge strategy did not reduce heads that are recorded in the final
commit correctly.
By Junio C Hamano (4) and Michał Kiedrowicz (1)
* jc/merge-reduce-parents-early:
fmt-merge-msg: discard needless merge parents
builtin/merge.c: reduce parents early
builtin/merge.c: collect other parents early
builtin/merge.c: remove "remoteheads" global variable
merge tests: octopus with redundant parents
Merge branch 'cb/cherry-pick-rev-path-confusion' into maint
The command line parser choked "git cherry-pick $name" when $name can be
both revision name and a pathname, even though $name can never be a path
in the context of the command.
By Clemens Buchacher
* cb/cherry-pick-rev-path-confusion:
cherry-pick: do not expect file arguments
HTTP transport that requires authentication did not work correctly when
multiple connections are used simultaneously.
By Jeff King (3) and Clemens Buchacher (1)
* cb/http-multi-curl-auth:
http: use newer curl options for setting credentials
http: clean up leak in init_curl_http_auth
fix http auth with multiple curl handles
http auth fails with multiple curl handles
Merge branch 'mb/fetch-call-a-non-branch-a-ref' into maint
The report from "git fetch" said "new branch" even for a non branch ref.
By Marc Branchaud
* mb/fetch-call-a-non-branch-a-ref:
fetch: describe new refs based on where it came from
fetch: Give remote_ref to update_local_ref() as well
Merge branch 'jm/maint-strncpy-diff-no-index' into maint
"diff --no-index" codepath had a few places that used fixed-size
buffer and truncated paths that are too long.
By Jim Meyering (1) and Junio C Hamano (1)
* jm/maint-strncpy-diff-no-index:
diff --no-index: use strbuf for temporary pathnames
diff: avoid stack-buffer-read-overrun for very long name
When "git fetch" encounters repositories with too many references, the
command line of "fetch-pack" that is run by a helper e.g. remote-curl, may
fail to hold all of them. Now such an internal invocation can feed the
references through the standard input of "fetch-pack".
By Ivan Todoroski
* it/fetch-pack-many-refs:
remote-curl: main test case for the OS command line overflow
fetch-pack: test cases for the new --stdin option
remote-curl: send the refs to fetch-pack on stdin
fetch-pack: new --stdin option to read refs from stdin
Merge branch 'jl/maint-submodule-recurse-fetch' into maint
"git fetch" that recurses into submodules on demand did not check if it
needs to go into submodules when non branches (most notably, tags) are
fetched.
By Jens Lehmann
* jl/maint-submodule-recurse-fetch:
submodules: recursive fetch also checks new tags for submodule commits
Merge branch 'lp/maint-diff-three-dash-with-graph' into maint
"log -p --graph" used with "--stat" had a few formatting error.
By Lucian Poston
* lp/maint-diff-three-dash-with-graph:
t4202: add test for "log --graph --stat -p" separator lines
log --graph: fix break in graph lines
log --graph --stat: three-dash separator should come after graph lines
Merge branch 'maint' of https://github.com/git-l10n/git-po
By Byrial Jensen (2) and others
via Jiang Xin (1) and Ralf Thielow (1)
* 'maint' of https://github.com/git-l10n/git-po:
l10n: Initial German translation
l10n: Update Simplified Chinese translation
l10n: Update git.pot (2 new messages)
l10n: Add the German translation team and initialize de.po
l10n: Add Danish team (da) to list of teams
l10n: New da.po file with 0 translations
l10n: Updated pt_PT language
While the majority of scripts use '#!/usr/bin/perl', some use
'#!/usr/bin/env perl'. In the end there is no difference, because the
Makefile rewrites "#!.*perl" with "#!$PERL_PATH" in scripted
Porcelains before installing. Nevertheless, the second form can be
misleading, because it suggests that perl found first in $PATH will be
used.
Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current code runs "perl gitweb.cgi" to test gitweb. This
will use whatever version of perl happens to be first in the
PATH. We are better off using the specific perl that the
user specified via PERL_PATH, which matches what gets put on
the #!-line of the built gitweb.cgi.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
log-tree: the previous one is still not quite right
The correct output would have NUL after each commit, so "-z --format=%s"
would have a single-liner subject with the line-terminating LF replaced
with NUL, and "-p/--stat -z --format=%s" would have a single-liner subject
with its line-terminating LF, followed by the diff/diffstat in which the
terminating LF of the last line is replaced with NUL, but to be consistent
with what "-p/--stat -z --pretty=format:%s" does, I think it is OK to
append NUL to the diff/diffstat part instead of replacing its last LF with
NUL.
The added test shows the update is still not right for "-p -z --format".
log-tree: use custom line terminator in line termination mode
When using a custom format in line termination mode (as opposed to line
separation mode), the configured line terminator is not used, so things
like "git log --pretty=tformat:%H -z" do not work properly.
Make it use the line terminator the user ordered.
Signed-off-by: Jan Krüger <jk@jk.gs> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, we tested only that "push --quiet --no-progress"
was silent. However, there are many other combinations that
were not tested:
1. no options at all (but stderr as a tty)
2. --no-progress by itself
3. --quiet by itself
4. --progress (when stderr not a tty)
These are tested elsewhere for general "push", but it is
important to test them separately for http. It follows a
very different code path than git://, and options must be
relayed across a remote helper to a separate send-pack
process (and in fact cases (1), (2), and (4) have all been
broken just for http at some point in the past).
We can drop the "--quiet --no-progress" test, as it is not
really interesting (it is already handled by testing them
separately in (2) and (3) above).
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The send_pack function gets a "progress" flag saying "yes,
definitely show progress" or "no, definitely do not show
progress". This gets set properly by transport_push when
send_pack is called directly.
However, when the send-pack command is executed separately
(as it is for the remote-curl helper), there is no way to
tell it "definitely do this". As a result, we do not
properly respect "git push --no-progress" for smart-http
remotes; you will still get progress if stderr is a tty.
This patch teaches send-pack --progress and --no-progress,
and teaches remote-curl to pass the appropriate option to
override send-pack's isatty check. This fixes the
--no-progress case above, and as a bonus, also makes "git
push --progress" work when stderr is not a tty.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
The send_pack_args struct has two verbosity flags: "quiet"
and "progress". Originally, if "quiet" was set, we would
tell pack-objects explicitly to be quiet, and if "progress"
was set, we would tell it to show progress. Otherwise, we
told it neither, and it relied on isatty(2) to make the
decision itself.
However, commit 01fdc21 changed the meaning of these
variables. Now both "quiet" and "!progress" instruct us to
tell pack-objects to be quiet (and a non-zero "progress"
means the same as before). This works well for transports
which call send_pack directly, as the transport code copies
transport->progress into send_pack_args->progress, and they
both have the same meaning.
However, the code path of calling "git send-pack" was left
behind. It always sets "progress" to 0, and thus always
tells pack-objects to be quiet. We can work around this by
checking isatty(2) ourselves in the cmd_send_pack code path,
restoring the original behavior of the send-pack command.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of sourcing git-sh-setup from random place that is on the $PATH,
explicitly source $(git --exec-path)/git-sh-setup. As I do not personally
have any libexec/git-core directory on my $PATH like many other people, the
script will fail without this update.
You can already use relative paths in include.path, which
means that including "foo" from your global "~/.gitconfig"
will look in your home directory. However, you might want to
do something clever like putting "~/.gitconfig-foo" in a
specific repository's config file.
Signed-off-by: Jeff King <peff@peff.net> Acked-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
mksh does not allow $COLUMNS to be set below 12. mksh(1) says that
$COLUMNS is "always set, defaults to 80, unless the value as reported
by stty(1) is non-zero and sane enough". This applies also to setting
it directly for one command:
t5570: fix forwarding of git-daemon messages via cat
The shell function that starts git-daemon wants to read the first line of
the daemon's stderr to ensure that it started correctly. Subsequent daemon
errors should be redirected to fd 4 (which is the terminal in verbose mode
or /dev/null in quiet mode). To that end the shell script used 'read' to
get the first line of output, and then 'cat &' to forward everything else
in a background process.
The problem is, that 'cat >&4 &' does not produce any output because the
shell redirects a background process's stdin to /dev/null. To have this
command invocation do anything useful, we have to redirect its stdin
explicitly (which overrides the /dev/null redirection).
The shell function connects the daemon's stderr to its consumers via a
FIFO. We cannot just do this:
read line <git_daemon_output
cat <git_daemon_output >&4 &
because after the first redirection the pipe is closed and the daemon
could receive SIGPIPE if it writes at the wrong moment. Therefore, we open
the readable end of the FIFO only once on fd 7 in the shell and dup from
there to the stdin of the two consumers.
Signed-off-by: Johannes Sixt <j6t@kdbg.org> Acked-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
In asciidoc 7, backticks like `foo` produced a typographic
effect, but did not otherwise affect the syntax. In asciidoc
8, backticks introduce an "inline literal" inside which markup
is not interpreted. To keep compatibility with existing
documents, asciidoc 8 has a "no-inline-literal" attribute to
keep the old behavior. We enabled this so that the
documentation could be built on either version.
It has been several years now, and asciidoc 7 is no longer
in wide use. We can now decide whether or not we want
inline literals on their own merits, which are:
1. The source is much easier to read when the literal
contains punctuation. You can use `master~1` instead
of `master{tilde}1`.
2. They are less error-prone. Because of point (1), we
tend to make mistakes and forget the extra layer of
quoting.
This patch removes the no-inline-literal attribute from the
Makefile and converts every use of backticks in the
documentation to an inline literal (they must be cleaned up,
or the example above would literally show "{tilde}" in the
output).
Problematic sites were found by grepping for '`.*[{\\]' and
examined and fixed manually. The results were then verified
by comparing the output of "html2text" on the set of
generated html pages. Doing so revealed that in addition to
making the source more readable, this patch fixes several
formatting bugs:
- HTML rendering used the ellipsis character instead of
literal "..." in code examples (like "git log A...B")
- some code examples used the right-arrow character
instead of '->' because they failed to quote
- api-config.txt did not quote tilde, and the resulting
HTML contained a bogus snippet like:
<tt><sub></tt> foo <tt></sub>bar</tt>
which caused some parsers to choke and omit whole
sections of the page.
- git-commit.txt confused ``foo`` (backticks inside a
literal) with ``foo'' (matched double-quotes)
- mentions of `A U Thor <author@example.com>` used to
erroneously auto-generate a mailto footnote for
author@example.com
- the description of --word-diff=plain incorrectly showed
the output as "[-removed-] and {added}", not "{+added+}".
- using "prime" notation like:
commit `C` and its replacement `C'`
confused asciidoc into thinking that everything between
the first backtick and the final apostrophe were meant
to be inside matched quotes
- asciidoc got confused by the escaping of some of our
asterisks. In particular,
`credential.\*` and `credential.<url>.\*`
properly escaped the asterisk in the first case, but
literally passed through the backslash in the second
case.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When PATH contains an unreadable directory, alias expansion code did
not kick in, and failed with an error that said "git-subcmd" was not
found.
By Jeff King (1) and Ramsay Jones (1)
* jk/run-command-eacces:
run-command: treat inaccessible directories as ENOENT
compat/mingw.[ch]: Change return type of exec functions to int
The 'push to upstream' implementation was broken in some corner
cases. "git push $there" without refspec, when the current branch is
set to push to a remote different from $there, used to push to $there
using the upstream information to a remote unreleated to $there.
* jc/push-upstream-sanity:
push: error out when the "upstream" semantics does not make sense
Merge branch 'jc/maint-clean-nested-worktree-in-subdir' into maint
"git clean -d -f" (not "-d -f -f") is supposed to protect nested
working trees of independent git repositories that exist in the
current project working tree from getting removed, but the protection
applied only to such working trees that are at the top-level of the
current project by mistake.
* jc/maint-clean-nested-worktree-in-subdir:
clean: preserve nested git worktree in subdirectories