Rather than hardcoding the maximum number of bytes which can be
mmapped from pack files we should make this value configurable,
allowing the end user to increase or decrease this limit on a
per-repository basis depending on the size of the repository
and the capabilities of their operating system.

In general users should not need to manually tune such a low-level
setting within the core code, but being able to artifically limit
the number of bytes which we can mmap at once from pack files will
make it easier to craft test cases for the new mmap sliding window
implementation.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The unpack_entry_gently function currently has only two callers:
the delta base resolution in sha1_file.c and the main loop of
pack-check.c.  Both of these must change to using unpack_entry
directly when we implement sliding window mmap logic, so I'm doing
it earlier to help break down the change set.

This may cause a slight performance decrease for delta base
resolution as well as for pack-check.c's verify_packfile(), as
the pack use counter will be incremented and decremented for every
object that is unpacked.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

* jc/curl:
  Work around http-fetch built with cURL 7.16.0

When '*.ig' is ignored, and you have two files f.ig and d.ig/foo
in the working tree,

	$ git add .

correctly ignored f.ig but failed to ignore d.ig/foo.  This was
caused by a thinko in an earlier commit 4888c534, when we tried
to allow adding otherwise ignored files.

After reverting that commit, this takes a much simpler approach.
When we have an unmatched pathspec that talks about an existing
pathname, we know it is an ignored path the user tried to add,
so we include it in the set of paths directory walker returned.

This does not let you say "git add -f D" on an ignored directory
D and add everything under D.  People can submit a patch to
further allow it if they want to, but I think it is a saner
behaviour to require explicit paths to be spelled out in such a
case.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This reverts commit 4888c534.

Signed-off-by: NJakub Narebski <jnareb@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Not that this reveals anything new, but I did test_tick shell
function in test-lib and found it rather cute and nice.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

* jc/utf8:
  t3900: test conversion to non UTF-8 as well
  Rename t3900 test vector file
  UTF-8: introduce i18n.logoutputencoding.
  Teach log family --encoding
  i18n.logToUTF8: convert commit log message to UTF-8
  Move encoding conversion routine out of mailinfo to utf8.c

Conflicts:

	commit.c

This changes the default remote.origin.fetch configuration
created by git-clone so that it allows non-fast-forward updates.

When using the separate-remote layout with reflog enabled, it
does not make much sense to refuse to update the remote tracking
branch just because some of them do not fast-forward.  git-fetch
issues warnings on non-fast-forwardness, and the user can peek
at what the previous state was using the reflog.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Not using reflog for tags/ was very sensible; not giving reflog
for the remotes/ was not.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

In some environments, certain tests have no way of succeeding
due to platform limitation, such as lack of 'unzip' program, or
filesystem that do not allow arbitrary sequence of non-NUL bytes
as pathnames.

You should be able to say something like

	$ cd t
	$ GIT_SKIP_TESTS=t9200.8 t9200-git-cvsexport-commit.sh

and even:

	$ GIT_SKIP_TESTS='t[0-4]??? t91?? t9200.8' make test

to omit such tests.  The value of the environment variable is a
SP separated list of patterns that tells which tests to skip,
and either can match the "t[0-9]{4}" part to skip the whole
test, or t[0-9]{4} followed by ".$number" to say which
particular test to skip.

Note that some tests in the existing test suite rely on previous
test item, so you cannot arbitrarily disable one and expect the
remainder of test to check what the test originally was intended
to check.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junkio@cox.net>

* jc/make:
  gcc does not necessarily pass runtime libpath with -R

Otherwise, sending the diagnostic to stdout would provoke a
protocol failure.
Signed-off-by: NJim Meyering <jim@meyering.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The function xdl_refine_conflicts() tries to break down huge
conflicts by doing a diff on the conflicting regions. However,
this does not make sense when one side is empty.

Worse, when one side is not only empty, but after EOF, the code
accessed unmapped memory.

Noticed by Luben Tuikov, Shawn Pearce and Alexandre Julliard, the
latter providing a test case.
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This looks a bit more pleasant for users.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Not sure how I missed this the first time around...
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This could be useful in finding new problems and helping users
debug.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

We have less code to worry about now.  As a bonus, --revision
can be used to reliably skip parts of history whenever fetch is
run, not just the first time.  I'm not sure why anybody would
want to skip history in the middle, however...

For people (nearly everyone at the moment) without the
do_switch() function in their Perl SVN library, the entire tree
must be refetched if --follow-parent is used and a parent is
found.  Future versions of SVN will have a working do_switch()
function accessible via Perl.

Accessing repositories on the local machine (especially file://
ones) is also slightly slower as a result; but I suspect most
git-svn users will be using it to access remote repositories.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Also, fixed an unportable use of 'export'.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

I don't think anybody running tests needs to know they're
running init-db and creating a repository for testing.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

We get an extra measure of error checking here as well.
While we're at it, also removed a less portable use of export.
Signed-off-by: NEric Wong <normalperson@yhbt.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

* js/shallow:
  fetch-pack: Do not fetch tags for shallow clones.
  get_shallow_commits: Avoid memory leak if a commit has been reached already.
  git-fetch: Reset shallow_depth before auto-following tags.
  upload-pack: Check for NOT_SHALLOW flag before sending a shallow to the client.
  fetch-pack: Properly remove the shallow file when it becomes empty.
  shallow clone: unparse and reparse an unshallowed commit
  Why didn't we mark want_obj as ~UNINTERESTING in the old code?
  Why does it mean we do not have to register shallow if we have one?
  We should make sure that the protocol is still extensible.
  add tests for shallow stuff
  Shallow clone: do not ignore shallowness when following tags
  allow deepening of a shallow repository
  allow cloning a repository "shallowly"
  support fetching into a shallow repository
  upload-pack: no longer call rev-list

Now that git-merge knows how to use the pull.{twohead,octopus}
configuration options to select the default merge strategy there
is no reason for git-pull to do the same immediately prior to
invoking git-merge.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

If git-merge is invoked without a strategy argument it is probably
being run as a porcelain-ish command directly and is not being run
from within git-pull.  However we still should honor whatever merge
strategy the user may have selected in their configuration, just as
`git-pull .` would have.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

If git-merge exits with a non-zero exit status so should git-pull.
This way the caller of git-pull knows the task did not complete
successfully simply by checking the process exit status.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

If a three-way merge in git-rebase generates a conflict then we
should take advantage of git-merge-recursive's ability to include
the branch name of each side of the conflict hunk by setting the
GITHEAD_* environment variables.

In the case of rebase there aren't really two clear branches; we
have the branch we are rebasing onto, and we have the branch we are
currently rebasing.  Since most conflicts will be arising between
the user's current branch and the branch they are rebasing onto
we assume the stuff that isn't in the current commit is the "onto"
branch and the stuff in the current commit is the "current" branch.

This assumption may however come up wrong if the user resolves one
conflict in such a way that it conflicts again on a future commit
also being rebased.  In this case the user's prior resolution will
appear to be in the "onto" part of the hunk.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

To help correctly log actions caused by porcelain which invoke
git-reset directly we should honor the setting of GIT_REFLOG_ACTION
which we inherited from our caller.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Junio rightly pointed out that the --reflog-action parameter
was starting to get out of control, as most porcelain code
needed to hand it to other porcelain and plumbing alike to
ensure the reflog contained the top-level user action and
not the lower-level actions it invoked.

At Junio's suggestion we are introducing the new set_reflog_action
function to all shell scripts, allowing them to declare early on
what their default reflog name should be, but this setting only
takes effect if the caller has not already set the GIT_REFLOG_ACTION
environment variable.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Following advice from CGI(3pm) man page, precompile all CGI routines
for mod_perl, in the BEGIN block.

  If you want to compile without importing use the compile() method
  instead:

    use CGI();
    CGI->compile();

  This is particularly useful in a mod_perl environment, in which you
  might want to precompile all CGI routines in a startup script, and then
  import the functions individually in each mod_perl script.
Signed-off-by: NJakub Narebski <jnareb@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Add mod_perl version string (the value of $ENV{'MOD_PERL'} if it is
set) to "generator" meta header.

The purpose of this is to identify version of gitweb, now that
codepath may differ for gitweb run as CGI script, run under
mod_perl 1.0 and run under mod_perl 2.0.
Signed-off-by: NJakub Narebski <jnareb@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

It appears ISO-2022-JP is more widely accepted than ISO2022JP, so
rename it that way.  We probably would need to have a way to skip
this test altogether in locale-challenged environments.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

It appears that curl_easy_duphandle() from libcurl 7.16.0
returns a curl session handle which fails GOOD_MULTI_HANDLE()
check in curl_multi_add_handle().  This causes fetch_ref() to
fail because start_active_slot() cannot start the request.

For now, check for 7.16.0 to work this issue around.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junkio@cox.net>

* sp/gc:
  Use 'repack -a -d -l' instead of 'repack -a -d' in git-gc
  everyday: replace a few 'prune' and 'repack' with 'gc'
  Create 'git gc' to perform common maintenance operations.

It is plausible for somebody to want to view the commit log in a
different encoding from i18n.commitencoding -- the project's
policy may be UTF-8 and the user may be using a commit message
hook to run iconv to conform to that policy (and either not have
i18n.commitencoding to default to UTF-8 or have it explicitly
set to UTF-8).  Even then, Latin-1 may be more convenient for
the usual pager and the terminal the user uses.

The new variable i18n.logoutputencoding is used in preference to
i18n.commitencoding to decide what encoding to recode the log
output in when git-log and friends formats the commit log message.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This should not be necessary for people who only use NTFS, but for
people with FAT32 it seems to be an issue.  Let's ship with a safer
default.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Otherwise we would end up slurping objects we borrow from
alternates.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Re-enable rev-list --parents for parse_commit which was removed in
(208b2dff).  rev-list --parents is not
just used to return the parent headers in the commit object, it
includes any grafts which are vaild for the commit.
Signed-off-by: NRobert Fitzsimons <robfitz@273k.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

If user hits enter at the prompt for
"Who should the emails appear to be from?",
the value for "From:" field was emptied instead of GIT_COMMITER_IDENT.
Signed-off-by: NQuy Tonthat <qtonthat@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>