tokkee.org

i18n: git-branch "(no branch)" message

Gettextize the "(no branch)" message that's shown by "git branch" when
you're in a detached HEAD.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

i18n: git-branch "git branch -v" messages

Make the "git branch -v" messages translatable, e.g.:

    5054b57 [ahead 8] branch error fixup

This is possibly a plumbing message.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

i18n: git-branch "Deleted branch [...]" message

Gettextize the "Deleted %sbranch %s (was %s).\n" messages. test in
t3200-branch.sh explicitly checked for this message. Change it to skip
under GETTEXT_POISON=YesPlease.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

i18n: git-branch "remote branch '%s' not found" message

This could be done better by splitting it up, but it would change too
much code, which I'm trying to avoid at this point. Instead add a
TRANSLATORS comment to explain what "remote " does.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

i18n: git-branch basic messages

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

i18n: git-add "Unstaged changes" message

Make the "Unstaged changes after refreshing the index:"
translatable. It's displayed under `git add --refresh --verbose`.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

i18n: git-add "remove '%s'" message

Make the "remove '%s'" message translatable. It's displayed under `git
add -u --verbose`. Also skip the corresponding test when output is not
in the C locale.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

i18n: git-add "did not match any files" message

Make the "did not match any files" message translatable, and skip the
test that checks for it when the C_LOCALE_OUTPUT prereq is not
present.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

i18n: git-add "The following paths are ignored" message

The tests t2204 (.gitignore) and t3700 (add) explicitly check for
these messages, so while at it, split each relevant test into a part
that just checks "git add"'s exit status and a part that checks
porcelain output.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

i18n: git-add basic messages

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

i18n: "make distclean" should clean up after "make pot"

This is in "make distclean" and not "make clean" to avoid needlessly
changing the POT-Creation-Date in the following scenario:

make clean; # cleaning up after an old build
git pull
make pot; # regenerate po template if necessary
msgmerge po/my_language.po po/git.pot

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

i18n: git-clone "Cloning into" message

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

i18n: Makefile: "pot" target to extract messages marked for translation

Add rules to generate a template (po/git.pot) listing messages marked
for translation in the C portion of git.

To get started translating, just run "make pot".

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

i18n: git-clone "Cloning into" message

Separate the "Cloning into %s" and "Cloning into bare repository %s"
messages to make them easier to translate. No noticeable change
intended.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

i18n: git-clone basic messages

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

i18n: git-init "Initialized [...] repository" message

These messages could benefit from splitting up.  An earlier version of
this patch began like this:

    const char *reinit_shared   = _("Reinitialized existing shared Git repository in %s\n");
    const char *init_shared     = _("Initialized empty shared Git repository in %s\n");
    const char *reinit_noshared = _("Reinitialized existing Git repository in %s\n");
    const char *init_noshared   = _("Initialized empty Git repository in %s\n");

But in the first round of gettextization I'm aiming to keep code
changes to a minimum for ease of review.  So just add a comment
explaining to translators how the sprintf format gets used so they
can cope for now if the language's grammar allows.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

i18n: git-init basic messages

Change the user visible strings in init-db.c to use gettext
localizations. This only converts messages which needed to be changed
from "foo" to _("foo"), and didn't need any TRANSLATORS comments.

I haven't marked the messages in init_db_usage or init_db_options for
translation, since that would require additional changes in
parse-options.c. Those can be done later.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

i18n: add stub Q_() wrapper for ngettext

The Q_ function translates a string representing some pharse with an
alternative plural form and uses the 'count' argument to choose which
form to return.  Use of Q_ solves the "%d noun(s)" problem in a way
that is portable to languages outside the Germanic and Romance
families.

In English, the semantics of Q_(sing, plur, count) are roughly
equivalent to

count == 1 ? _(sing) : _(plur)

while in other languages there can be more variants (count == 0; more
random-looking rules based on the historical pronunciation of the
number).  Behind the scenes, the singular form is used to look up a
family of translations and the plural form is ignored unless no
translation is available.

Define such a Q_ in gettext.h with the English semantics so C code can
start using it to mark phrases with a count for translation.

The name "Q_" is taken from subversion and stands for "quantity".
Many projects just use ngettext directly without a wrapper analogous
to _; we should not do so because git's gettext.h is meant not to
conflict with system headers that might include libintl.h.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Update Release Notes to 1.7.5

Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'js/cherry-pick-usability'

* js/cherry-pick-usability:
  Teach commit about CHERRY_PICK_HEAD
  bash: teach __git_ps1 about CHERRY_PICK_HEAD
  Introduce CHERRY_PICK_HEAD
  t3507: introduce pristine-detach helper

Merge branch 'js/checkout-untracked-symlink'

* js/checkout-untracked-symlink:
  do not overwrite untracked symlinks
  Demonstrate breakage: checkout overwrites untracked symlink with directory

Merge branch 'so/submodule-no-update-first-time'

* so/submodule-no-update-first-time:
  t7406: "git submodule update {--merge|--rebase]" with new submodules
  submodule: no [--merge|--rebase] when newly cloned

git-log.txt,rev-list-options.txt: put option blocks in proper order

Match the order of the description to the one in which they get applied:

  commit limiting
  commit ordering
  commit formatting
  diff options

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

log: fix --max-count when used together with -S or -G

The --max-count limit is implemented by counting revisions in
get_revision(), but the -S and -G take effect later when running diff.
Hence "--max-count=10 -Sfoo" meant "examine the 10 first revisions, and
out of them, show only those changing the occurences of foo", not "show 10
revisions changing the occurences of foo".

In case the commit isn't actually shown, cancel the decrement of
max_count.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint'

* maint:
  Fix typo in t/README
  ls-remote documentation: <refs> argument is optional
  Add Author and Documentation sections to git-for-each-ref.txt
  Documentation: remove redundant colons in git-for-each-ref.txt

t6007: test rev-list --cherry

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

log --cherry: a synonym

At the porcelain level, because by definition there are many more contributors
than integrators, it makes sense to give a handy short-hand for --right-only
used with --cherry-mark and --no-merges.  Make it so.

In other words, this provides "git cherry with rev-list interface".

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

rev-list: documentation and test for --cherry-mark

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

revision.c: introduce --cherry-mark

for marking those commits which "--cherry-pick" would drop.
The marker for those commits is '=' because '-' denotes a boundary
commit already, even though 'git cherry' uses it.

Nonequivalent commits are denoted '+' unless '--left-right' is used.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

rev-list/log: factor out revision mark generation

Currently, we have identical code for generating revision marks ('<',
'>', '-') in 5 places.

Factor out the code to a single function get_revision_mark() for easier
maintenance and extensibility.

Note that the check for !!revs in graph.c (which gets removed
effectively by this patch) is superfluous.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fetch/pull: Describe --recurse-submodule restrictions in the BUGS section

Using the --recurse-submodules option with fetch and pull might not always
fetch all the submodule commits the user expects, as this will only work
when the submodule is already checked out. Document that and warn that
this is expected to change in the future.

Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

submodule update: Don't fetch when the submodule commit is already present

If the commit to be checked out on "git submodule update" has already been
fetched in the submodule there is no need to run "git fetch" again. Since
"git fetch" recently learned recursion (and the new on-demand mode to
fetch commits recorded in the superproject is enabled by default) this
will happen pretty often, thereby making the unconditional fetch during
"git submodule update" unnecessary.

If the commit is not present in the submodule (e.g. the user disabled the
fetch on-demand mode) the fetch will be run as before.

Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fetch/pull: Don't recurse into a submodule when commits are already present

When looking for submodules where new commits have been recorded in the
superproject ignore those cases where the submodules commits are already
present locally. This can happen e.g. when the submodule has been rewound
to an earlier state. Then there is no need to fetch the submodule again
as the commit recorded in the newly fetched superproject commit has
already been fetched earlier into the submodule.

Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Submodules: Add 'on-demand' value for the 'fetchRecurseSubmodule' option

Now the behavior of fetch and pull can be configured to the recently added
'on-demand' mode separately for each submodule too.

Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

config: teach the fetch.recurseSubmodules option the 'on-demand' value

To enable the user to change the default behavior of "git fetch" and "git
pull" regarding submodule recursion add the new "on-demand" value which
has just been added to the "--recurse-submodules" command line option.

Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fetch/pull: Add the 'on-demand' value to the --recurse-submodules option

Until now the --recurse-submodules option could only be used to either
fetch all populated submodules recursively or to disable recursion
completely. As fetch and pull now by default just fetch those submodules
for which new commits have been fetched in the superproject, a command
line option to enforce that behavior is needed to be able to override
configuration settings.

Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

fetch/pull: recurse into submodules when necessary

To be able to access all commits of populated submodules referenced by the
superproject it is sufficient to only then let "git fetch" recurse into a
submodule when the new commits fetched in the superproject record new
commits for it. Having these commits present is extremely useful when
using the "--submodule" option to "git diff" (which is what "git gui" and
"gitk" do since 1.6.6), as all submodule commits needed for creating a
descriptive output can be accessed. Also merging submodule commits (added
in 1.7.3) depends on the submodule commits in question being present to
work. Last but not least this enables disconnected operation when using
submodules, as all commits necessary for a successful "git submodule
update -N" will have been fetched automatically. So we choose this mode as
the default for fetch and pull.

Before a new or changed ref from upstream is updated in update_local_ref()
"git rev-list <new-sha1> --not --branches --remotes" is used to determine
all newly fetched commits. These are then walked and diffed against their
parent(s) to see if a submodule has been changed. If that is the case, its
path is stored to be fetched after the superproject fetch is completed.

Using the "--recurse-submodules" or the "--no-recurse-submodules" option
disables the examination of the fetched refs because the result will be
ignored anyway.

There is currently no infrastructure for storing deleted and new
submodules in the .git directory of the superproject. That's why fetch and
pull for now only fetch submodules that are already checked out and are
not renamed.

In t7403 the "--no-recurse-submodules" argument had to be added to "git
pull" to avoid failure because of the moved upstream submodule repo.

Thanks-to: Jonathan Nieder <jrnieder@gmail.com>
Thanks-to: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fix typo in t/README

Signed-off-by: Mathias Lafeldt <misfire@debugon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

ls-remote documentation: <refs> argument is optional

Correct SYNOPSIS section.

Signed-off-by: Piotr Krukowiecki <piotr.krukowiecki@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Add Author and Documentation sections to git-for-each-ref.txt

Signed-off-by: Alexei Sholik <alcosholik@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: remove redundant colons in git-for-each-ref.txt

Signed-off-by: Alexei Sholik <alcosholik@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitk: Quote tag names in event bindings to avoid problems with % chars

Tag names that contain a % character require quoting when used in event
bindings or the name may be mis-recognised for percent substitution in
the event script.

Reported-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>

gitk: Allow user to control how much of the SHA1 ID gets auto-selected

This adds a new spinbox on the Edit Preferences pane to allow the user
to control how many characters of the SHA1 ID get autoselected.

Signed-off-by: Paul Mackerras <paulus@samba.org>

Merge branch 'maint'

* maint:
  SubmittingPatches: clarify the expected commit log description
  diff format documentation: clarify --cc and -c
  rev-list-options.txt: typo fix

transport-helper.c: fix check for (size_t < 0)

'bytes' is of type size_t which is unsigned thus can't be negative.  But
the assigned write() returns ssize_t, and -1 on error.

For testing < 0, 'bytes' needs to be of a signed type.

Signed-off-by: Nicolas Kaiser <nikai@nikai.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

SubmittingPatches: clarify the expected commit log description

Earlier, 47afed5 (SubmittingPatches: itemize and reflect upon well written
changes, 2009-04-28) added a discussion on the contents of the commit log
message, but the last part of the new paragraph didn't make much sense.
Reword it slightly to make it more readable.

Update the "quicklist" to clarify what we mean by "motivation" and
"contrast".  Also mildly discourage external references.

Signed-off-by: Junio C Hamano <gitster@pobox.com>

diff format documentation: clarify --cc and -c

The description was unclear if -c or --cc was the default (--cc is for
some commands), and incorrectly implied that the default applies to
all the diff generating commands.

Most importantly, "log" does not default to "--cc" (it defaults to
"--no-merges") and "log -p" obeys the user's wish to see non-combined
format.  Only "diff" (during merge and three-blob comparison) and
"show" use --cc as the default.

Signed-off-by: Adam Monsen <haircut@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

commit, status: use status_printf{,_ln,_more} helpers

wt-status code is used to provide a reminder of changes included and
not included for the commit message template opened in the operator's
text editor by "git commit".  Therefore each line of its output begins
with the comment character "#":

# Please enter the commit message for your changes. Lines starting

Use the new status_printf{,_ln,_more} functions to take care of adding
"#" to the beginning of such status lines automatically.  Using these
will have two advantages over the current code:

 - The obvious one is to force separation of the "#" from the
   translatable part of the message when git learns to translate its
   output.

 - Another advantage is that this makes it easier for us to drop "#"
   prefix in "git status" output in later versions of git if we want
   to.

Explained-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

commit: refer to commit template as s->fp

Instead of maintaining a local variable for it, use s->fp to keep
track of where the commit message template should be written.

This prepares us to take advantage of the status_printf functions,
which use a struct wt_status instead of a FILE pointer to determine
where to send their output.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

wt-status: add helpers for printing wt-status lines

Introduce status_printf{,_ln,_more} wrapper functions around
color_vfprintf() which take care of adding "#" to the beginning of
status lines automatically.  The semantics:

 - status_printf() is just like color_fprintf() but it adds a "# "
   at the beginning of each line of output;

 - status_printf_ln() is a convenience function that additionally
   adds "\n" at the end;

 - status_printf_more() is a variant of status_printf() used to
   continue lines that have already started.  It suppresses the "#" at
   the beginning of the first line.

Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

trace: give repo_setup trace its own key

You no longer get this output with GIT_TRACE=1; instead, you
can do GIT_TRACE_SETUP=1.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

add packet tracing debug code

This shows a trace of all packets coming in or out of a given
program. This can help with debugging object negotiation or
other protocol issues.

To keep the code changes simple, we operate at the lowest
level, meaning we don't necessarily understand what's in the
packets. The one exception is a packet starting with "PACK",
which causes us to skip that packet and turn off tracing
(since the gigantic pack data will not be interesting to
read, at least not in the trace format).

We show both written and read packets. In the local case,
this may mean you will see packets twice (written by the
sender and read by the receiver). However, for cases where
the other end is remote, this allows you to see the full
conversation.

Packet tracing can be enabled with GIT_TRACE_PACKET=<foo>,
where <foo> takes the same arguments as GIT_TRACE.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

trace: add trace_strbuf

If you happen to have a strbuf, it is a little more readable
and a little more efficient to be able to print it directly
instead of jamming it through the trace_printf interface.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

trace: factor out "do we want to trace" logic

As we add more tracing areas, this will avoid repeated code.

Technically, trace_printf already checks this and will avoid
printing if the trace key is not set. However, callers may
want to find out early whether or not tracing is enabled so
they can avoid doing work in the common non-trace case.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

trace: refactor to support multiple env variables

Right now you turn all tracing off and on with GIT_TRACE. To
support new types of tracing without forcing the user to see
all of them, we will soon support turning each tracing area
on with GIT_TRACE_*.

This patch lays the groundwork by providing an interface
which does not assume GIT_TRACE. However, we still maintain
the trace_printf interface so that existing callers do not
need to be refactored.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

trace: add trace_vprintf

This is a necessary cleanup to adding new types of trace
functions.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

i18n: do not poison translations unless GIT_GETTEXT_POISON envvar is set

Tweak the GETTEXT_POISON facility so it is activated at run time
instead of compile time.  If the GIT_GETTEXT_POISON environment
variable is set, _(msg) will result in gibberish as before; but if the
GIT_GETTEXT_POISON variable is not set, it will return the message for
human-readable output.  So the behavior of mistranslated and
untranslated git can be compared without rebuilding git in between.

For simplicity we always set the GIT_GETTEXT_POISON variable in tests.

This does not affect builds without the GETTEXT_POISON compile-time
option set, so non-i18n git will not be slowed down.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

i18n: add GETTEXT_POISON to simulate unfriendly translator

Add a new GETTEXT_POISON compile-time parameter to make _(msg) always
return gibberish. So now you can run

make GETTEXT_POISON=YesPlease

to get a copy of git that functions correctly (one hopes) but produces
output that is in nobody's native language at all.

This is a debugging aid for people who are working on the i18n part of
the system, to make sure that they are not marking plumbing messages
that should never be translated with _().

As new strings get marked for translation, naturally a number of tests
will be broken in this mode. Tests that depend on output from
Porcelain will need to be marked with the new C_LOCALE_OUTPUT test
prerequisite. Newly failing tests that do not depend on output from
Porcelain would be bugs due to messages that should not have been
marked for translation.

Note that the string we're using ("# GETTEXT POISON #") intentionally
starts the pound sign. Some of Git's tests such as
t3404-rebase-interactive.sh rely on interactive editing with a fake
editor, and will needlessly break if the message doesn't start with
something the interactive editor considers a comment.

A future patch will fix fix the underlying cause of that issue by
adding "#" characters to the commit advice automatically.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

i18n: add no-op _() and N_() wrappers

The _ function is for translating strings into the user's chosen
language.  The N_ macro just marks translatable strings for the
xgettext(1) tool without translating them; it is intended for use in
contexts where a function call cannot be used.  So, for example:

fprintf(stderr, _("Expansion of alias '%s' failed; "
"'%s' is not a git command\n"),
cmd, argv[0]);

and

const char *unpack_plumbing_errors[NB_UNPACK_TREES_ERROR_TYPES] = {
/* ERROR_WOULD_OVERWRITE */
N_("Entry '%s' would be overwritten by merge. Cannot merge."),
[...]

Define such _ and N_ in a new gettext.h and include it in cache.h, so
they can be used everywhere.  Each just returns its argument for now.
_ is a function rather than a macro like N_ to avoid the temptation to
use _("foo") as a string literal (which would be a compile-time error
once _(s) expands to an expression for the translation of s).

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

commit, status: use status_printf{,_ln,_more} helpers

wt-status code is used to provide a reminder of changes included and
not included for the commit message template opened in the operator's
text editor by "git commit".  Therefore each line of its output begins
with the comment character "#":

# Please enter the commit message for your changes. Lines starting

Use the new status_printf{,_ln,_more} functions to take care of adding
"#" to the beginning of such status lines automatically.  Using these
will have two advantages over the current code:

 - The obvious one is to force separation of the "#" from the
   translatable part of the message when git learns to translate its
   output.

 - Another advantage is that this makes it easier for us to drop "#"
   prefix in "git status" output in later versions of git if we want
   to.

Explained-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

commit: refer to commit template as s->fp

Instead of maintaining a local variable for it, use s->fp to keep
track of where the commit message template should be written.

This prepares us to take advantage of the status_printf functions,
which use a struct wt_status instead of a FILE pointer to determine
where to send their output.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

wt-status: add helpers for printing wt-status lines

Introduce status_printf{,_ln,_more} wrapper functions around
color_vfprintf() which take care of adding "#" to the beginning of
status lines automatically.  The semantics:

 - status_printf() is just like color_fprintf() but it adds a "# "
   at the beginning of each line of output;

 - status_printf_ln() is a convenience function that additionally
   adds "\n" at the end;

 - status_printf_more() is a variant of status_printf() used to
   continue lines that have already started.  It suppresses the "#" at
   the beginning of the first line.

Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

compat: fall back on __va_copy if available

Since an obvious implementation of va_list is to make it a pointer
into the stack frame, implementing va_copy as "dst = src" will work on
many systems.  Platforms that use something different (e.g., a size-1
array of structs, to be assigned with *(dst) = *(src)) will need some
other compatibility macro, though.

Luckily, as the glibc manual hints, such systems tend to provide the
__va_copy macro (introduced in GCC in March, 1997).  By using that if
it is available, we can cover our bases pretty well.

Discovered by building with CC="gcc -std=c89" on an amd64 machine:

 $ make CC=c89 strbuf.o
 [...]
 strbuf.c: In function 'strbuf_vaddf':
 strbuf.c:211:2: error: incompatible types when assigning to type 'va_list'
  from type 'struct __va_list_tag *'
 make: *** [strbuf.o] Error 1

Explained-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-log.txt,rev-list-options.txt: -n/--max-count is commit limiting

They are applied after commit ordering and formatting options, in
particular --reverse.

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

rev-list-options.txt: typo fix

Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-compat-util.h: Honor HP C's noreturn attribute

HP C for Integrity servers (Itanium) gained support for noreturn
attribute sometime in 2006. It was released in Compiler Version
A.06.10 and made available in July 2006.

The __HP_cc define detects the HP C compiler version.  Precede the
__GNUC__ check so it works well when compiling with HP C using -Agcc
option that enables partial support for the GNU C dialect. The -Agcc
defines the __GNUC__ too.

Signed-off-by: Michal Rokos <michal.rokos@nextsoft.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Makefile: add NO_FNMATCH_CASEFOLD to HP-UX section

fnmatch() on HP-UX does not support the GNU FNM_CASEFOLD extension,
so set NO_FNMATCH_CASEFOLD to use the internal fnmatch implementation.

Signed-off-by: Michal Rokos <michal.rokos@nextsoft.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

vcs-svn: use mark from previous import for parent commit

With this patch, overlapping incremental imports work.

Signed-off-by: David Barr <david.barr@cordelta.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>

vcs-svn: handle filenames with dq correctly

Quote paths passed to fast-import so filenames with double quotes are
not misinterpreted.

One might imagine this could help with filenames with newlines, too,
but svn does not allow those.

Helped-by: David Barr <daivd.barr@cordelta.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: David Barr <david.barr@cordelta.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>

vcs-svn: quote paths correctly for ls command

This bug was found while importing rev 601865 of ASF.

[jn: with test]

Signed-off-by: David Barr <david.barr@cordelta.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>

vcs-svn: eliminate repo_tree structure

Rely on fast-import for information about previous revs.

This requires always setting up backward flow of information, even for
v2 dumps.  On the plus side, it simplifies the code by quite a bit and
opens the door to further simplifications.

[db: adjusted to support final version of the cat-blob patch]
[jn: avoiding hard-coding git's name for the empty tree for
 portability to other backends]

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: David Barr <david.barr@cordelta.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>

vcs-svn: add a comment before each commit

Current svn-fe produces output like this:

blob
mark :7382321
data 5
hello

blob
mark :7382322
data 5
Hello

commit
mark :3
[...]
M 100644 :7382321 hello.c
M 100644 :7382322 hello2.c

This means svn-fe has to keep track of the paths modified in each
commit and the corresponding marks, instead of dealing with each file
as it arrives in input and then forgetting about it.  A better
strategy would be to use inline blobs:

commit
mark :3
[...]
M 100644 inline hello.c
data 5
hello
[...]

As a first step towards that, teach svn-fe to notice when the
collection of blobs for each commit starts and write a comment
("# commit 3.") there.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>

vcs-svn: save marks for imported commits

This way, a person can use

svnadmin dump $path |
svn-fe |
git fast-import --relative-marks --export-marks=svn-revs

to get a list of what commit corresponds to each svn revision (plus
some irrelevant blob names) in .git/info/fast-import/svn-revs.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: David Barr <david.barr@cordelta.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>

vcs-svn: use higher mark numbers for blobs

Prepare to use mark :5 for the commit corresponding to r5 (and so on).

1 billion seems sufficiently high for blob marks to avoid conflicting
with rev marks, while still leaving room for 3 billion blobs.  Such
high mark numbers cause trouble with ancient fast-import versions, but
this topic cannot support git fast-import versions before 1.7.4 (which
introduces the cat-blob command) anyway.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>

vcs-svn: set up channel to read fast-import cat-blob response

Set up some plumbing: teach the svndump lib to pass a file descriptor
number to the fast_export lib, representing where cat-blob/ls
responses can be read from, and add a get_response_line helper
function to the fast_export lib to read a line from that file.

Unfortunately this means that svn-fe needs file descriptor 3 to be
redirected from somewhere (preferrably the cat-blob stream of a
fast-import backend); otherwise it will fail:

$ svndump <path> | svn-fe
fatal: cannot read from file descriptor 3: Bad file descriptor

For the moment, "svn-fe 3</dev/null" works as a workaround but it
will not work for very long.  A fast-import backend that can retrieve
old commits is needed in order to be able to fulfill svn
"Node-copyfrom-rev" requests that refer to revs from a previous run.

[jn: with new change description]

Based-on-patch-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: David Barr <david.barr@cordelta.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>

vcs-svn: allow input errors to be detected promptly

The line_buffer library silently flags input errors until
buffer_deinit time; unfortunately, by that point usually errno is
invalid.  Expose the error flag so callers can check for and
report errors early for easy debugging.

some_error_prone_operation(...);
if (buffer_ferror(buf))
return error("input error: %s", strerror(errno));

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: David Barr <david.barr@cordelta.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>

vcs-svn: simplify repo_modify_path and repo_copy

Restrict the repo_tree API to functions that are actually needed.

 - decouple reading the mode and content of dirents from other
   operations.
 - remove repo_modify_path.  It is only used to read the mode from
   dirents.
 - remove the ability to use repo_read_mode on a missing path.  The
   existing code only errors out in that case, anyway.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: David Barr <david.barr@cordelta.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>

vcs-svn: handle_node: use repo_read_path

svn-fe processes each commit in two stages: first decide on the
correct content for all paths and export the relevant blobs, then
export a commit with the result.

But we can keep less state and simplify svn-fe a great deal by
exporting the commit in one step: use 'inline' blobs for each path and
remember nothing.  This way, the repo_tree structure could be
eliminated, and we would get support for incremental imports 'for
free'.

Reorganize handle_node along these lines.  This is just a code
cleanup; the changes in repo_tree and handle_revision will come later.

[db: backported to apply without text delta support]

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: David Barr <david.barr@cordelta.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>

vcs-svn: introduce repo_read_path to check the content at a path

The repo_tree structure remembers, for each path in each revision, a
mode (regular file, executable, symlink, or directory) and content
(blob mark or directory structure).  Maintaining a second copy of all
this information when it's already in the target repository is
wasteful, it does not persist between svn-fe invocations, and most
importantly, there is no convenient way to transfer it from one
machine to another.  So it would be nice to get rid of it.

As a first step, let's change the repo_tree API to match fast-import's
read commands more closely.  Currently to read the mode for a path,
one uses

repo_modify_path(path, new_mode, new_content);

which changes the mode and content as a side effect.  There is no
function to read the content at a path; add one.

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: David Barr <david.barr@cordelta.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>

apply -v: show offset count when patch did not apply exactly

When the line number the patch intended to touch does not match
the line in the version being patched, GNU patch reports that
it applied the hunk at a different line number, with how big an
offset.

Teach "git apply" to do the same under --verbose option.

Signed-off-by: Junio C Hamano <gitster@pobox.com>

rebase: define options in OPTIONS_SPEC

Interactive rebase used to have its own command line processing. Since
it used the 'git rev-parse --parseopt' functionality exposed through
git-sh-setup, it had some flexibility, like matching prefixes of long
options, that non-interactive rebase didn't. When interactive rebase's
command line processing was factored out into git-rebase.sh in cf432ca
(rebase: factor out command line option processing, 2011-02-06), this
flexibility was lost. Give back that flexibility to interactive and
non-interactive by defining its options in OPTIONS_SPEC.

Also improve the usage message to contain the --continue, --skip and
--abort sub commands.

Reported-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint'

* maint:
  Documentation: fix a typo in git-apply.txt
  init: remove unnecessary check

Merge branch 'mh/p4'

* mh/p4:
  git-p4 submit: prevent 'Jobs' section from being removed from p4 change log

Merge branch 'mg/maint-difftool-vim-readonly'

* mg/maint-difftool-vim-readonly:
  mergetool-lib: call vim in readonly mode for diffs

Merge branch 'jn/maint-commit-missing-template'

* jn/maint-commit-missing-template:
  commit: error out for missing commit message template

Merge branch 'jk/diffstat-binary'

* jk/diffstat-binary:
  diff: don't retrieve binary blobs for diffstat
  diff: handle diffstat of rewritten binary files

Merge branch 'lt/rename-no-extra-copy-detection'

* lt/rename-no-extra-copy-detection:
  diffcore-rename: improve estimate_similarity() heuristics
  diffcore-rename: properly honor the difference between -M and -C
  for_each_hash: allow passing a 'void *data' pointer to callback

Merge branch 'jn/test-terminal-punt-on-osx-breakage'

* jn/test-terminal-punt-on-osx-breakage:
  tests: skip terminal output tests on OS X

Merge branch 'jk/fail-null-clone'

* jk/fail-null-clone:
  clone: die when trying to clone missing local path

Merge branch 'jc/grep--no-index-pathspec-fix'

* jc/grep--no-index-pathspec-fix:
  grep --no-index: honor pathspecs correctly

apply: do not patch lines that were already patched

When looking for a place to apply a hunk, we used to check lines that
match the preimage of it, starting from the line that the patch wants to
apply the hunk at, looking forward and backward with increasing offsets
until we find a match.

Colin Guthrie found an interesting case where this misapplied a patch that
wanted to touch a preimage that consists of

                        }
                }

                return 0;
        }

which is a rather unfortunately common pattern.

The target version of the file originally had only one such location, but
the hunk immediately before that created another instance of such block of
lines, and find_pos() happily reported that the preimage of the hunk
matched what it wanted to modify.

Oops.

By marking the lines application of earlier hunks touched and preventing
match_fragment() from considering them as a match with preimage of other
hunks, we can reduce such an accident.

I also considered to teach apply_one_fragment() to take the offset we have
found while applying the previous hunk into account when looking for a
match with find_pos(), but dismissed that approach, because it would
sometimes work better but sometimes worse, depending on the difference
between the version the patch was created against and the version the
patch is being applied.

This does _not_ prevent misapplication of patches to a file that has many
similar looking blocks of lines and a preimage cannot identify which one
of them should be applied.  For that, we would need to scan beyond the
first match in find_pos(), and issue a warning (or error out).  That will
be a separate topic.

Signed-off-by: Junio C Hamano <gitster@pobox.com>

Documentation: fix a typo in git-apply.txt

git-apply accepts the --cached option, not --cache.

Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

init: remove unnecessary check

git_dir must always be non-NULL so "if (git_dir)" is unnecessary.
Before this code, if git_dir == NULL, it will default to
DEFAULT_GIT_DIR_ENVIRONMENT.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

push: better error message when no remote configured

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

push: better error messages when push.default = tracking

A common scenario is to create a new branch and push it (checkout -b &&
push [--set-upstream]). In this case, the user was getting "The current
branch %s has no upstream branch.", which doesn't help much.

Provide the user a command to push the current branch. To avoid the
situation in the future, suggest --set-upstream.

While we're there, also improve the error message in the "detached HEAD"
case. We mention explicitly "detached HEAD" since this is the keyword to
look for in documentations.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'maint'

* maint:
  verify-pack: add --stat-only to the synopsis section

git-request-pull: open-code the only invocation of get_remote_url

So sh:get_remote_url can go now and git-request-pull
doesn't need to source git-parse-remote. anymore.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

get_remote_url(): use the same data source as ls-remote to get remote urls

The formerly implemented algorithm behaved differently to
remote.c:remote_get() at least for remotes that contain a slash.  While the
former just assumes a/b is a path the latter checks the config for
remote."a/b" first which is more reasonable.

This removes the last user of git-parse-remote.sh:get_data_source(), so
this function is removed.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

rerere forget: deprecate invocation without pathspec

rerere forget is a destructive command. When invoked without a path, it
operates on the current directory, potentially deleting many recorded
conflict resolutions.

To make the command safer, a path must be specified as of git 1.8.0. Until
then, give users time to write 'git rerere forget .' if they really mean
the entire current directory.

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

merge-recursive: When we detect we can skip an update, actually skip it

In 882fd11 (merge-recursive: Delay content merging for renames 2010-09-20),
there was code that checked for whether we could skip updating a file in
the working directory, based on whether the merged version matched the
current working copy.  Due to the desire to handle directory/file conflicts
that were resolvable, that commit deferred content merging by first
updating the index with the unmerged entries and then moving the actual
merging (along with the skip-the-content-update check) to another function
that ran later in the merge process.  As part moving the content merging
code, a bug was introduced such that although the message about skipping
the update would be printed (whenever GIT_MERGE_VERBOSITY was sufficiently
high), the file would be unconditionally updated in the working copy
anyway.

When we detect that the file does not need to be updated in the working
copy, update the index appropriately and then return early before updating
the working copy.

Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>