i18n: make the translation of -u advice in one go

The advice (consider use of -u when read_directory takes too long) is
separated into 3 different status_printf_ln() calls, and which brings
trouble for translators.

Since status_vprintf() called by status_printf_ln() can handle eol in
buffer, we could simply join these lines into one paragraph.

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
Reviewed-by: Eric Sunshine <sunshine@sunshineco.com>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'tb/document-status-u-tradeoff' into maint

* tb/document-status-u-tradeoff:
  i18n: make the translation of -u advice in one go
Documentation: distinguish between ref and offset deltas in pack-format

eb32d236 introduced the OBJ_OFS_DELTA object that uses a relative offset to
identify the base object instead of the 20-byte SHA1 reference. The pack file
documentation only mentions the SHA1 based reference in its description of the
deltified object entry.

Update the pack format documentation to clarify that the deltified object
representation refers to its base using either a relative negative offset or
the absolute SHA1 identifier.

Signed-off-by: Stefan Saasen <ssaasen@atlassian.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fast-export: fix argument name in error messages

The --signed-tags argument is plural, while error messages referred
to --signed-tag (singular).  Tweak error messages to correspond to the
argument.

Signed-off-by: Paul Price <price@astro.princeton.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
help: mark common_guides[] as translatable

Signed-off-by: Simon Ruderich <simon@ruderich.org>
Acked-by: Philip Oakley <philipoakley@iee.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
doc: clarify that "git daemon --user=<user>" option does not export HOME=~user

The fact that we don't set $HOME may confuse admins who expect
~<user>/.gitconfig to be used, because that is not what we try to
read.  And worse, since 96b9e0e3, a git-daemon started by root is
likely to fail to run at all, as the user we switch to generally
cannot read ~root.

Signed-off-by: Jeff King <peff@peff.net>
Helped-by: W. Trevor King <wking@tremily.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
completion: add more cherry-pick options

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
completion: trivial test improvement

Instead of passing a dummy "", let's check if the last character is a
space, and then move the _cword accordingly.

Apparently we were passing "" all the way to compgen, which fortunately
expanded it to nothing.

Lets do the right thing though.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
completion: get rid of empty COMPREPLY assignments

There's no functional reason for those, the only purpose they are
supposed to serve is to say "we don't provide any words here", but
even for that it's not used consistently.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
completion: add new __gitcompadd helper

The idea is to never touch the COMPREPLY variable directly.

This allows other completion systems (i.e. zsh) to override
__gitcompadd, and do something different instead.

Also, this allows further optimizations down the line.

There should be no functional changes.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
SQUASH??? avoid referencing undefined positional vars???
completion: add __gitcomp_nl tests

Original patch by SZEDER Gábor.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
completion: get rid of compgen

The functionality we use from compgen is not much, we can do the same
manually, with drastic improvements in speed, especially when dealing
with only a few words.

This patch also has the sideffect that brekage reported by Jeroen Meijer
and SZEDER Gábor gets fixed because we no longer expand the resulting
words.

Here are some numbers filtering N amount of words:

  == 1 ==
  original: 0.002s
  new: 0.000s
  == 10 ==
  original: 0.002s
  new: 0.000s
  == 100 ==
  original: 0.003s
  new: 0.002s
  == 1000 ==
  original: 0.012s
  new: 0.011s
  == 10000 ==
  original: 0.056s
  new: 0.066s
  == 100000 ==
  original: 2.669s
  new: 0.622s

If the results are not narrowed:

  == 1 ==
  original: 0.002s
  new: 0.000s
  == 10 ==
  original: 0.002s
  new: 0.001s
  == 100 ==
  original: 0.004s
  new: 0.004s
  == 1000 ==
  original: 0.020s
  new: 0.015s
  == 10000 ==
  original: 0.101s
  new: 0.355s
  == 100000 ==
  original: 2.850s
  new: 31.941s

So, unless 'git checkout <tab>' usually gives you more than 10000
results, you'll get an improvement :)

Other possible solutions perform better after 1000 words, but worst if
less than that:

  COMPREPLY=($(awk -v cur="$3" -v pre="$2" -v suf="$4"
	'$0 ~ cur { print pre$0suf }' <<< "$1" ))

  COMPREPLY=($(printf -- "$2%s$4\n" $1 | grep "^$2$3"))

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
completion: inline __gitcomp_1 to its sole callsite

There is no point in calling a separate function that is only used
in one place. Especially considering that there's no need to call
compgen, and we traverse the words ourselves both in __gitcompadd,
and __gitcomp_1.

Let's squash the functions together, and traverse only once.

This improves performance. For N number of words:

  == 1 ==
  original: 0.002s
  new: 0.000s
  == 10 ==
  original: 0.005s
  new: 0.001s
  == 100 ==
  original: 0.009s
  new: 0.006s
  == 1000 ==
  original: 0.027s
  new: 0.019s
  == 10000 ==
  original: 0.163s
  new: 0.151s
  == 100000 ==
  original: 1.555s
  new: 1.497s

No functional changes.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
completion: small optimization

No need to calculate a new $c with a space if we are not going to do
anything it with it.

There should be no functional changes, except that a word "foo " with no
suffixes can't be matched. But $cur cannot have a space at the end
anyway. So it's safe.

Based on the code from SZEDER Gábor.

Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t4211: pass -M to 'git log -M -L...' test

Embarrassingly, the -M test did not actually invoke -M, and thus not
really test the feature.

Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
log -L: test merge of parallel modify/rename

This tests a toy example of a history like

  * Merge
  | \
  |  * Modify foo
  |  |
  *  | Rename foo->bar
  | /
  * Create foo

Current log -L fails on this; we'll fix it in the next commit.

Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
log -L: store the path instead of a diff_filespec

line_log_data has held a diff_filespec* since the very early versions
of the code.  However, the only place in the code where we actually
need the full filespec is parse_range_arg(); in all other cases, we
are only interested in the path, so there is hardly a reason to store
a filespec.  Even worse, it causes a lot of redundant ->spec->path
pointer dereferencing.

And *even* worse, it caused the following bug.  If you merge a rename
with a modification to the old filename, like so:

  * Merge
  | \
  |  * Modify foo
  |  |
  *  | Rename foo->bar
  | /
  * Create foo

we internally -- in process_ranges_merge_commit() -- scan all parents.
We are mainly looking for one that doesn't have any modifications, so
that we can assign all the blame to it and simplify away the merge.
In doing so, we run the normal machinery on all parents in a loop.
For each parent, we prepare a "working set" line_log_data by making a
copy with line_log_data_copy(), which does *not* make a copy of the
spec.

Now suppose the rename is the first parent.  The diff machinery tells
us that the filepair is ('foo', 'bar').  We duly update the path we
are interested in:

  rg->spec->path = xstrdup(pair->one->path);

But that 'struct spec' is shared between the output line_log_data and
the original input line_log_data.  So we just wrecked the state of
process_ranges_merge_commit().  When we get around to the second
parent, the ranges tell us we are interested in a file 'foo' while the
commits touch 'bar'.

So most of this patch is just s/->spec->path/->path/ and associated
management changes.  This implicitly fixes the bug because we removed
the shared parts between input and output of line_log_data_copy(); it
is now safe to overwrite the path in the copy.

There's one only somewhat related change: the comment in
process_all_files() explains the reasoning behind using 'range' there.
That bit of half-correct code had me sidetracked for a while.

Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
log -L: improve comments in process_all_files()

The funny range assignment in process_all_files() had me sidetracked
while investigating what led to the previous commit.  Let's improve
the comments.

Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'maint-1.8.1' into maint

* maint-1.8.1:
  fast-export: fix argument name in error messages
  Documentation: distinguish between ref and offset deltas in pack-format