vcs-svn: rename check_overflow and its arguments for clarity

The canonical interpretation of a range a,b is as an interval [a,b),
not [a,a+b), so this function taking argument names a and b feels
unnatural.  Use more explicit names "offset" and "len" to make the
arguments' type and function clearer.

While at it, rename the function to convey that we are making sure
the sum of this offset and length do not overflow an off_t, not a
size_t.

[jn: split out from a patch from Ramsay Jones, then improved with
 advice from Thomas Rast, Dmitry Ivankov, and David Barr]

Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Improved-by: Dmitry Ivankov <divanorama@gmail.com>
vcs-svn: allow import of > 4GiB files

There is no reason in principle that an svn-format dump would not
be able to represent a file whose length does not fit in a 32-bit
integer.  Use off_t consistently (instead of uint32_t) to represent
file lengths so we can handle that.

Most of our code is already ready to do that without this patch and
already passes values of type off_t around.  The type mismatch due to
stragglers was noticed with gcc -Wtype-limits.

Inspired-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
vcs-svn: suppress -Wtype-limits warning

On 32-bit architectures with 64-bit file offsets, gcc 4.3 and earlier
produce the following warning:

	    CC vcs-svn/sliding_window.o
	vcs-svn/sliding_window.c: In function `check_overflow':
	vcs-svn/sliding_window.c:36: warning: comparison is always false \
	    due to limited range of data type

The warning appears even when gcc is run without any warning flags
(PR12963).  In later versions it can be reproduced with -Wtype-limits,
which is implied by -Wextra.

On 64-bit architectures it really is possible for a size_t not to be
representable as an off_t so the check being warned about is not
actually redundant.  But even false positives are distracting.  Avoid
the warning by making the "len" argument to check_overflow a
uintmax_t; no functional change intended.

Reported-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Demonstrate git-show is broken with ranges

The logic of git-show has remained largely unchanged since around
5d7eeee (git-show: grok blobs, trees and tags, too, 2006-12-14): start
a revision walker with no_walk=1, look at its pending objects and
handle them one-by-one.  For commits, this means stuffing them into a
new queue all alone, and running the walker.

Then Linus's f222abd (Make 'git show' more useful, 2009-07-13) came
along and set no_walk=0 whenever the user specifies a range.  Which
appears to work fine, until you actually prod it hard enough, as the
preceding commit shows: UNINTERESTING commits will be marked as such,
but not walked further to propagate the marks.

Demonstrate this with the main tests of this patch: 'showing a range
walks (Y shape)'.  The Y shape of history ensures that propagating the
UNINTERESTING marks is necessary to correctly exclude the main1
commit.  The only example I could find actually requires that the
negative revisions are listed later, and in this scenario a dotted
range actually works.  However, it is easy to find examples in git.git
where a dotted range is wrong, e.g.

  $ git show v1.7.0..v1.7.1 | grep ^commit | wc -l
  1297
  $ git rev-list v1.7.0..v1.7.1 | wc -l
  702

While there, also test a few other things that are not covered so far:
the -N way of triggering a range (added in 5853cae, DWIM 'git show -5'
to 'git show --do-walk -5', 2010-06-01), and the interactions of tags,
commits and ranges.

Pointed out by Dr_Memory on #git.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
show: fix "range implies walking"

Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff-index.c: do not pretend paths are pathspecs

"git diff --no-index" takes exactly two paths, not pathspecs, and
has its own way queue_diff() to populate the diff_queue.  Do not
call diff_tree_setup_paths(), pretending as it takes pathspecs.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff-index.c: unify handling of command line paths

Regardless of where in the directory hierarchy you are, "-" on the
command line means the standard input.  The old code knew too much
about how the low level machinery uses paths to read from the
working tree and did not bother to have the same check for "-" when
the command is run from the top-level.

Unify the codepaths for subdirectory case and toplevel case into one
and make it clearer.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff-index.c: "git diff" has no need to read blob from the standard input

Only "diff --no-index -" does.  Bolting the logic into the low-level
function diff_populate_filespec() was a layering violation from day
one.  Move populate_from_stdin() function out of the generic diff.c
to its only user, diff-index.c.

Also make sure "-" from the command line stays a special token "read
from the standard input", even if we later decide to sanitize the
result from prefix_filename() function in a few obvious ways,
e.g. removing unnecessary "./" prefix, duplicated slashes "//" in
the middle, etc.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
l10n: Update git.pot (29 new messages)

Generate po/git.pot from v1.7.11.1-107-g72601, and there are 29 new l10n
messages.

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
l10n: Update translation for Vietnamese

 * Translated 29 news
 * Fix some minor errors in old translation

Signed-off-by: Tran Ngoc Quan <vnwildman@gmail.com>
push: don't guess at qualifying remote refs on deletion

When we try to push a ref and the right-hand side of the
refspec does not find a match, we try to create it. If it is
not fully qualified, we try to guess where it would go in
the refs hierarchy based on the left-hand source side. If
the source side is not a ref, then we give up and give a
long explanatory message.

For deletions, however, this doesn't make any sense. We
would never want to create on the remote side, and if an
unqualified ref can't be matched, it is simply an error. The
current code handles this already because the left-hand side
is empty, and therefore does not give us a hint as to where
the right-hand side should go, and we properly error out.
Unfortunately, the error message is the long "we tried to
qualify this, but the source side didn't let us guess"
message, which is quite confusing.

Instead, we can just be more succinct and say "we can't
delete this because we couldn't find it". So before:

  $ git push origin :bogus
  error: unable to push to unqualified destination: bogus
  The destination refspec neither matches an existing ref on the remote nor
  begins with refs/, and we are unable to guess a prefix based on the source ref.
  error: failed to push some refs to '$URL'

and now:

  $ git push origin :bogus
  error: unable to delete 'bogus': remote ref does not exist
  error: failed to push some refs to '$URL'

It is tempting to also catch a fully-qualified ref like
"refs/heads/bogus" and generate the same error message.
However, that currently does not error out at all, and
instead gets sent to the remote side, which typically
generates a warning:

  $ git push origin:refs/heads/bogus
  remote: warning: Deleting a non-existent ref.
  To $URL
   - [deleted]         bogus

While it would be nice to catch this error early, a
client-side error would mean aborting the push entirely and
changing push's exit code. For example, right now you can
do:

  $ git push origin refs/heads/foo refs/heads/bar

and end up in a state where "foo" and "bar" are deleted,
whether both of them currently exist or not (and see an
error only if we actually failed to contact the server).
Generating an error would cause a regression for this use
case.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Update Swedish translation (1095t0f0u)

Signed-off-by: Peter Krefting <peter@softwolves.pp.se>
git-remote-mediawiki: improve support for non-English Wikis

Mediafiles can live in namespaces with names different from Image
and File. While at it, rework the code to make it simpler and easier
to read.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
l10n: de.po: translate 29 new messages

Translate 29 new messages came from git.pot update
in 11b9017 (l10n: Update git.pot (29 new messages)).

Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
l10n: zh_CN.po: translate 29 new messages

Translate 29 new messages came from git.pot update in 11b9017
(l10n: Update git.pot (29 new messages))

Signed-off-by: Jiang Xin <worldhello.net@gmail.com>
vcs-svn: drop no-op reset methods

Since v1.7.5~42^2~6 (vcs-svn: remove buffer_read_string)
buffer_reset() does nothing thus fast_export_reset() also.

Signed-off-by: David Barr <davidbarr@google.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
vcs-svn: avoid self-assignment in dummy initialization of pre_off

Without this change, clang complains:

 vcs-svn/svndiff.c:298:3: warning: Assigned value is garbage or undefined
                 off_t pre_off = pre_off; /* stupid GCC... */
                 ^               ~~~~~~~

This code uses an old and common idiom for suppressing an
"uninitialized variable" warning, and clang is wrong to warn about it.
The idiom tells the compiler to leave the variable uninitialized,
which saves a few bytes of code size, and, more importantly, allows
valgrind to check at runtime that the variable is properly initialized
by the time it is used.

But MSVC and clang do not know that idiom, so let's avoid it in
vcs-svn/ code.

Initialize pre_off to -1, a recognizably meaningless value, to allow
future code changes that cause pre_off to be used before it is
initialized to be caught early.

Signed-off-by: David Barr <davidbarr@google.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
vcs-svn: simplify cleanup in apply_one_window

Currently the cleanup code looks like this:

	free resources
	return 0;
 error_out:
	free resources
	return -1;

Avoid duplicating the "free resources" part by keeping the return
value in a variable and sharing code between the success and
exceptional case:

	ret = 0;
 out:
	free resources
	return ret;

Noticed in the svn-dump-fast-export project, where using the error()
macro in void context produces a warning.

Signed-off-by: David Barr <davidbarr@google.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
vcs-svn: use constcmp instead of prefixcmp

Since the length of t is already known, we can simplify a little by
using memcmp() instead of strncmp() to carry out a prefix comparison.
All nearby code already does this.

Noticed in the standalone svn-dump-fast-export project which has not
needed to implement prefixcmp() yet.

Signed-off-by: David Barr <davidbarr@google.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
vcs-svn: use strstr instead of memmem

memmem is a GNU extension.

Avoiding it makes the code clearer and makes it easier for projects
that don't share git's compat/ code, such as the standalone
svn-dump-fast-export project, to reuse the vcs-svn/ library.

Signed-off-by: David Barr <davidbarr@google.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>