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>
sha1_name.c: indentation fix

Signed-off-by: Junio C Hamano <gitster@pobox.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>
Makefile: sort LIB_H list

This was mostly sorted already, but put things like
"cache-tree.h" after "cache.h", even though "-" comes before
"." (at least in the C locale). This will make it easier to
keep the list sorted later by piping it through "sort".

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Makefile: fold MISC_H into LIB_H

We keep a list of most of the header files in LIB_H, but
some are split out into MISC_H. The original point
of LIB_H was that it would force recompilation of C files
when any of the library headers changed. It was
over-encompassing, since not all C files included all of the
library headers; this made it simple to maintain, but meant
that we sometimes recompiled when it was not necessary.

Over time, some new headers were omitted from LIB_H, and
rules were added to the Makefile for a few specific targets
to explicitly depend on them. This avoided some unnecessary
recompilation at the cost of having to maintain the
dependency list of those targets manually (e.g., d349a03).

Later, we needed a complete list of headers from which we
should extract strings to localized. Thus 1b8b2e4 introduced
MISC_H to mention all header files not included in LIB_H,
and the concatenation of the two lists is fed to xgettext.
Headers mentioned as dependencies must also be manually
added to MISC_H to receive the benefits of localization.

Having to update multiple locations manually is a pain and
has led to errors. For example, see "git log -Swt-status.h
Makefile" for some back-and-forth between the two locations.
Or the fact that column.h was never added to MISC_H, and
therefore was not localized (which is fixed by this patch).
Moreover, the benefits of keeping these few headers out of
LIB_H is not that great, for two reasons:

  1. The better way to do this is by auto-computing the
     dependencies, which is more accurate and less work to
     maintain. If your compiler supports it, we turn on
     computed header dependencies by default these days. So
     these manual dependencies are used only for people who
     do not have gcc at all (which increases the chance of
     them becoming stale, as many developers will never even
     use them).

  2. Even if you do not have gcc, the manual header
     dependencies do not help all that much.  They obviously
     cannot help with an initial compilation (since their
     purpose is to avoid unnecessary recompilation when a
     header changes), which means they are only useful when
     building a new version of git in the working tree that
     held an existing build (e.g., after checkout or during a
     bisection). But since a change of a header in LIB_H
     will force recompilation, and given that the vast
     majority of headers are in LIB_H, most version changes
     will result in a full rebuild anyway.

Let's just fold MISC_H into LIB_H and get rid of these
manual rules. The worst case is some extra compilation, but
even that is unlikely to matter due to the reasons above.

The one exception is that we should keep common-cmds.h
separate. Because it is generated, the computed dependencies
do not handle it properly, and we must keep separate
individual dependencies on it. Let's therefore rename MISC_H
to GENERATED_H to make it more clear what should go in it.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
test-lib: reorder and include GIT-BUILD-OPTIONS a lot earlier

This dot-sources GIT-BUILD-OPTIONS a lot earlier in test-lib.sh so
that its use of "perl" can use "$PERL_PATH" to choose the version of
Perl the user told us is suitable for our use.

This is iffy; I didn't check it very carefully, and I would not be
surprised if there are subtle breakages.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
rebase: don't source git-sh-setup twice

The git-sh-setup script is already sourced in git-rebase.sh before
calling into git-rebase--(am|interactive|merge).sh. There are no other
callers of these scripts. It is therefore unnecessary to source
git-sh-setup again in them.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
rebase --root: print usage on too many args

Just like

  git rebase --onto newbase upstream branch error

displays the usage message, so should clearly

  git rebase --onto newbase --root branch error

, but it doesn't. Instead, it ignores both "branch" and "error" and
rebases the current HEAD. This is because we try to match the number
of remainging arguments "$#", which fails to match "1" argument and
matches the "*" that really should have been a "0".

Make sure we display usage information when too many arguments are
given. Also fail-fast in case of similar bugs in the future by
matching on exactly 0 arguments and failing on unknown numbers.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
am --rebasing: get patch body from commit, not from mailbox

Rebasing a commit that contains a diff in the commit message results
in a failure with output such as

  First, rewinding head to replay your work on top of it...
  Applying: My cool patch.
  fatal: sha1 information is lacking or useless
  (app/controllers/settings_controller.rb).
  Repository lacks necessary blobs to fall back on 3-way merge.
  Cannot fall back to three-way merge.
  Patch failed at 0001 My cool patch.

The reason is that 'git rebase' without -p/-i/-m internally calls 'git
format-patch' and pipes the output to 'git am --rebasing', which has
no way of knowing what is a real patch and what is a commit message
that contains a patch.

Make 'git am' while in --rebasing mode get the patch body from the
commit object instead of extracting it from the mailbox.

Patch by Junio, test case and commit log message by Martin.

Reported-by: anikey <arty.anikey@gmail.com>
Helped-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
am: don't call mailinfo if $rebasing

Since 5e835ca (rebase: do not munge commit log message, 2008-04-16),
'git am --rebasing' no longer gets the commit log message from the
patch, but reads it from the commit identified by the "From " header
line. From 43c2325 (am: use get_author_ident_from_commit instead of
mailinfo when rebasing, 2010-06-16), it also gets the author name,
email and date from the commit. Now that the final part of the patch
-- the patch body itself -- is also read from the commit, there is no
longer a need to call 'git mailinfo' to extract any of these parts
while --rebasing.

Sugested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
rebase -i: support --root without --onto

Allow --root to be specified to rebase -i without --onto, making it
possible to edit and re-order all commits right back to the root(s).

If there is a conflict to be resolved when applying the first change,
the user will expect a sane index and working tree to get sensible
behaviour from git-diff and friends, so create a sentinel commit with an
empty tree to rebase onto. Automatically squash the sentinel with any
commits rebased directly onto it, so they end up as root commits in
their own right and retain their authorship and commit message.

Implicitly use rebase -i for non-interactive rebase of --root without
an --onto argument now that rebase -i can correctly do this.

Signed-off-by: Chris Webb <chris@arachsys.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add tests for rebase -i --root without --onto

Test for likely breakages in t3404, including successful reordering of
non-conflicting changes with a new root, correct preservation of commit
message and author in a root commit when it is squashed with the
sentinel, and presence of the sentinel following a conflicting
cherry-pick of a new root.

Remove test_must_fail for git rebase --root without --onto from t3412 as
this case will now be successfully handled by an implicit git rebase -i.

Signed-off-by: Chris Webb <chris@arachsys.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-remote-mediawiki: don't compute the diff when getting commit message

While we're there, simplify the code a bit: since log --format=%s anyway
shows the subject line as a single line, no need to split to take the
first line.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-remote-mediawiki: don't "use encoding 'utf8';"

The use of this statement is generally discouraged, and is too intrusive
for us: it forces the HTTP requests made by the API to contain only valid
UTF-8 characters. This would break the upload of binary files.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-remote-mediawiki: send "File:" attachments to a remote wiki

The current version of the git-remote-mediawiki supports only import and
export of plain wiki pages. This patch adds the functionality to export
file attachments (i.e. the content of the File: MediaWiki namespace),
which are also exposed by MediaWiki API.

This requires a recent version of MediaWiki::API (Version 0.37 works.
Version 0.34 doesn't).

Signed-off-by: Pavel Volek <Pavel.Volek@ensimag.imag.fr>
Signed-off-by: NGUYEN Kim Thuat <Kim-Thuat.Nguyen@ensimag.imag.fr>
Signed-off-by: ROUCHER IGLESIAS Javier <roucherj@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-remote-mediawiki: split get_mw_pages into smaller functions

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-remote-mediawiki: import "File:" attachments

Add the symmetrical feature to the "File:" export support in the previous
patch. Download files from the wiki as needed, and feed them into the
fast-import stream. Import both the file itself, and the corresponding
description page.

Signed-off-by: Pavel Volek <Pavel.Volek@ensimag.imag.fr>
Signed-off-by: NGUYEN Kim Thuat <Kim-Thuat.Nguyen@ensimag.imag.fr>
Signed-off-by: ROUCHER IGLESIAS Javier <roucherj@ensimag.imag.fr>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>