Release pack windows before reporting out of memory.

If we are about to fail because this process has run out of memory we
should first try to automatically control our appetite for address
space by releasing enough least-recently-used pack windows to gain
back enough memory such that we might actually be able to meet the
current allocation request.

This should help users who have fairly large repositories but are
working on systems with relatively small virtual address space.
Many times we see reports on the mailing list of these users running
out of memory during various Git operations.  Dynamically decreasing
the amount of pack memory used when the demand for heap memory is
increasing is an intelligent solution to this problem.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Default core.packdGitWindowSize to 1 MiB if NO_MMAP.

If the compiler has asked us to disable use of mmap() on their
platform then we are forced to use git_mmap and its emulation via
pread.  In this case large (e.g. 32 MiB) windows for pack access
are simply too big as a command will wind up reading a lot more
data than it will ever need, significantly reducing response time.

To prevent a high latency when NO_MMAP has been selected we now
use a default of 1 MiB for core.packedGitWindowSize.  Credit goes
to Linus and Junio for recommending this more reasonable setting.

[jc: upcased the name of the symbolic constant, and made another
 hardcoded constant into a symbolic constant while at it. ]

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Test suite for sliding window mmap implementation.

This is a basic set of tests for the sliding window mmap.  We mostly
focus on the verify-pack and pack-objects implementations (including
delta reuse) as these commands appear to cover the bulk of the
affected portions of sha1_file.c.

The test cases don't verify the virtual memory size used, as
this can differ from system to system.  Instead it just verifies
that we can run with very low values for core.packedGitLimit and
core.packedGitWindowSize.

Adding pack_report() to the end of both builtin-verify-pack.c and
builtin-pack-objects.c and manually inspecting the statistics output
can help to verify that the total virtual memory size attributed
to pack mmap usage is what one might expect on the current system.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Create pack_report() as a debugging aid.

Much like the alloc_report() function can be useful to report on
object allocation statistics while debugging the new pack_report()
function can be useful to report on the behavior of the mmap window
code used for packfile access.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Support unmapping windows on 'temporary' packfiles.

If a command opens a packfile for only temporary access and does not
install the struct packed_git* into the global packed_git list then
we are unable to unmap any inactive windows within that packed_git,
causing the overall process to exceed core.packedGitLimit.

We cannot force the callers to install their temporary packfile
into the packed_git chain as doing so would allow that (possibly
corrupt but currently being verified) temporary packfile to become
part of the local ODB, which may allow it to be considered for
object resolution when it may not actually be a valid packfile.

So to support unmapping the windows of these temporary packfiles we
also scan the windows of the struct packed_git which was supplied
to use_pack().  Since commands only work with one temporary packfile
at a time scanning the one supplied to use_pack() and all packs
installed into packed_git should cover everything available in
memory.

We also have to be careful to not close the file descriptor of
the packed_git which was handed to use_pack() when all of that
packfile's windows have been unmapped, as we are already past the
open call that would open the packfile and need the file descriptor
to be ready for mmap() after unuse_one_window returns.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Improve error message when packfile mmap fails.

If we are unable to mmap the a region of the packfile with the mmap()
system call there may be a good reason why, such as a closed file
descriptor or out of address space.  Reporting the system level
error message can help to debug such problems.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Ensure core.packedGitWindowSize cannot be less than 2 pages.

We cannot allow a window to be smaller than 2 system pages.
This limitation is necessary to support the feature of use_pack()
where we always supply at least 20 bytes after the offset to help
the object header and delta base parsing routines.

If packedGitWindowSize were allowed to be as small as 1 system page
then we would be completely unable to access an object header which
spanned over a page as we would never be able to arrange a mapping
such that the header was contiguous in virtual memory.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Load core configuration in git-verify-pack.

Now that our pack access code's behavior may be altered by the
setting of core.packedGitWindowSize or core.packedGitLimit we need
to make sure these values are set as configured in the repository's
configuration file rather than to their defaults.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Fully activate the sliding window pack access.

This finally turns on the sliding window behavior for packfile data
access by mapping limited size windows and chaining them under the
packed_git->windows list.

We consider a given byte offset to be within the window only if there
would be at least 20 bytes (one hash worth of data) accessible after
the requested offset.  This range selection relates to the contract
that use_pack() makes with its callers, allowing them to access
one hash or one object header without needing to call use_pack()
for every byte of data obtained.

In the worst case scenario we will map the same page of data twice
into memory: once at the end of one window and once again at the
start of the next window.  This duplicate page mapping will happen
only when an object header or a delta base reference is spanned
over the end of a window and is always limited to just one page of
duplication, as no sane operating system will ever have a page size
smaller than a hash.

I am assuming that the possible wasted page of virtual address
space is going to perform faster than the alternatives, which
would be to copy the object header or ref delta into a temporary
buffer prior to parsing, or to check the window range on every byte
during header parsing.  We may decide to revisit this decision in
the future since this is just a gut instinct decision and has not
actually been proven out by experimental testing.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Unmap individual windows rather than entire files.

To support multiple windows per packfile we need to unmap only one
window at a time from that packfile, leaving any other windows in
place and available for reference.

We treat all windows from all packfiles equally; the least recently
used, not-in-use window across all packfiles will always be closed
first.

If we have unmapped all windows in a packfile then we can also close
the packfile's file descriptor as its possible we won't need to map
any window from that file in the near future.  This decision about
when to close the pack file descriptor may need to be revisited in
the future after additional testing on several different platforms
can be performed.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Document why header parsing won't exceed a window.

When we parse the object header or the delta base reference we
don't bother to loop over use_pack() calls.  The reason we don't
need to bother with calling use_pack for each byte accessed is that
use_pack will always promise us at least 20 bytes (really the hash
size) after the offset.  This promise from use_pack simplifies a
lot of code in the header parsing logic, as well as helps out the
zlib library by ensuring there's always some data for it to consume
during an inflate call.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Loop over pack_windows when inflating/accessing data.

When multiple mmaps start getting used for all pack file access it
is not possible to get all data associated with a specific object
in one contiguous memory region.  This limitation prevents simply
passing a single address and length to SHA1_Update or to inflate.

Instead we need to loop until we have processed all data of interest.

As we loop over the data we are always interested in reusing the same
window 'cursor', as the prior window will no longer be of any use
to us.  This allows the use_pack() call to automatically decrement
the use count of the prior window before setting up access for us
to the next window.

Within each loop we need to make use of the available length output
parameter of use_pack() to tell us how many bytes are available in
the current memory region, as we cannot tell otherwise.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Replace use_packed_git with window cursors.

Part of the implementation concept of the sliding mmap window for
pack access is to permit multiple windows per pack to be mapped
independently.  Since the inuse_cnt is associated with the mmap and
not with the file, this value is in struct pack_window and needs to
be incremented/decremented for each pack_window accessed by any code.

To faciliate that implementation we need to replace all uses of
use_packed_git() and unuse_packed_git() with a different API that
follows struct pack_window objects rather than struct packed_git.

The way this works is when we need to start accessing a pack for
the first time we should setup a new window 'cursor' by declaring
a local and setting it to NULL:

  struct pack_windows *w_curs = NULL;

To obtain the memory region which contains a specific section of
the pack file we invoke use_pack(), supplying the address of our
current window cursor:

  unsigned int len;
  unsigned char *addr = use_pack(p, &w_curs, offset, &len);

the returned address `addr` will be the first byte at `offset`
within the pack file.  The optional variable len will also be
updated with the number of bytes remaining following the address.

Multiple calls to use_pack() with the same window cursor will
update the window cursor, moving it from one window to another
when necessary.  In this way each window cursor variable maintains
only one struct pack_window inuse at a time.

Finally before exiting the scope which originally declared the window
cursor we must invoke unuse_pack() to unuse the current window (which
may be different from the one that was first obtained from use_pack):

  unuse_pack(&w_curs);

This implementation is still not complete with regards to multiple
windows, as only one window per pack file is supported right now.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Refactor how we open pack files to prepare for multiple windows.

To efficiently support mmaping of multiple regions of the same pack
file we want to keep the pack's file descriptor open while we are
actively working with that pack.  So we are now keeping that file
descriptor in packed_git.pack_fd and closing it only after we unmap
the last window.

This is going to increase the number of file descriptors that are
in use at once, however that will be bounded by the total number of
pack files present and therefore should not be very high.  It is
a small tradeoff which we may need to revisit after some testing
can be done on various repositories and systems.

For code clarity we also want to seperate out the implementation
of how we open a pack file from the implementation which locates
a suitable window (or makes a new one) from the given pack file.
Since this is a rather large delta I'm taking advantage of doing
it now, in a fairly isolated change.

When we open a pack file we need to examine the header and trailer
without having a mmap in place, as we may only need to mmap
the middle section of this particular pack.  Consequently the
verification code has been refactored to make use of the new
read_or_die function.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Create read_or_die utility routine.

Like write_or_die read_or_die reads the entire length requested
or it kills the current process with a die call.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Use off_t for index and pack file lengths.

Since the index_size and pack_size members of struct packed_git
are the lengths of those corresponding files we should use the
off_t size of the operating system to store these file lengths,
rather than an unsigned long.  This would help in the future should
we ever resurrect Junio's 64 bit index implementation.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Refactor packed_git to prepare for sliding mmap windows.

The idea behind the sliding mmap window pack reader implementation
is to have multiple mmap regions active against the same pack file,
thereby allowing the process to mmap in only the active/hot sections
of the pack and reduce overall virtual address space usage.

To implement this we need to refactor the mmap related data
(pack_base, pack_use_cnt) out of struct packed_git and move them
into a new struct pack_window.

We are refactoring the code to support a single struct pack_window
per packfile, thereby emulating the prior behavior of mmap'ing the
entire pack file.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Introduce new config option for mmap limit.

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: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Replace unpack_entry_gently with unpack_entry.

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: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Merge branch 'jc/curl'

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

Fix 'git add' with .gitignore

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: Junio C Hamano <junkio@cox.net>

Revert "read_directory: show_both option."

This reverts commit 4888c534099012d71d24051deb5b14319747bd1a.

Add info about new test families (8 and 9) to t/README

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

t5400 send-pack test: try a bit more nontrivial transfer.

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: Junio C Hamano <junkio@cox.net>

Merge branch 'jc/utf8'

* 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

Allow non-fast-forward of remote tracking branches in default clone

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: Junio C Hamano <junkio@cox.net>

core.logallrefupdates: log remotes/ tracking branches.

Not using reflog for tags/ was very sensible; not giving reflog
for the remotes/ was not.

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

GIT_SKIP_TESTS: allow users to omit tests that are known to break

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: Junio C Hamano <junkio@cox.net>

t3900: test conversion to non UTF-8 as well

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

Merge branch 'jc/make'

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

update hook: redirect _both_ diagnostic lines to stderr upon tag failure

Otherwise, sending the diagnostic to stdout would provoke a
protocol failure.

Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

xdl_merge(): fix a segmentation fault when refining conflicts

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: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>

git-svn: sort multi-init output

This looks a bit more pleasant for users.

Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

git-svn: verify_ref() should actually --verify

Not sure how I missed this the first time around...

Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

git-svn: print out the SVN library version in --version, too

This could be useful in finding new problems and helping users
debug.

Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

git-svn: remove non-delta fetch code paths

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: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

t9200-git-cvsexportcommit.sh: quiet down commit

Also, fixed an unportable use of 'export'.

Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

test-lib: quiet down init-db output for tests

I don't think anybody running tests needs to know they're
running init-db and creating a repository for testing.

Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

t6024-recursive-merge: quiet down this test

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: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Merge branch 'js/shallow'

* 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

Allow git-merge to select the default strategy.

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: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Honor pull.{twohead,octopus} in git-merge.

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: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Ensure `git-pull` fails if `git-merge` fails.

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: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Use branch names in 'git-rebase -m' conflict hunks.

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: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Honor GIT_REFLOG_ACTION in git-rebase.

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: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Use GIT_REFLOG_ACTION environment variable instead.

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: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

gitweb: Precompile CGI routines for mod_perl

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: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

gitweb: Add mod_perl version string to "generator" meta header

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: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Rename t3900 test vector file

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: Junio C Hamano <junkio@cox.net>

Work around http-fetch built with cURL 7.16.0

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: Junio C Hamano <junkio@cox.net>

gcc does not necessarily pass runtime libpath with -R

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

Merge branch 'sp/gc'

* 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.

UTF-8: introduce i18n.logoutputencoding.

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: Junio C Hamano <junkio@cox.net>

Set NO_MMAP for Cygwin by default

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: Junio C Hamano <junkio@cox.net>

Use 'repack -a -d -l' instead of 'repack -a -d' in git-gc

Otherwise we would end up slurping objects we borrow from
alternates.

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

gitweb: Re-enable rev-list --parents for parse_commit.

Re-enable rev-list --parents for parse_commit which was removed in
(208b2dff95bb48682c351099023a1cbb0e1edf26).  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: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

git-send-email: default value for "From:" field.

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: Quy Tonthat <qtonthat@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Merge branch 'master' into js/shallow

This is to adjust to:

  count-objects -v: show number of packs as well.

which will break a test in this series.

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

everyday: replace a few 'prune' and 'repack' with 'gc'

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

Create 'git gc' to perform common maintenance operations.

Junio asked for a 'git gc' utility which users can execute on a
regular basis to perform basic repository actions such as:

 * pack-refs --prune
 * reflog expire
 * repack -a -d
 * prune
 * rerere gc

So here is a command which does exactly that.  The parameters fed
to reflog's expire subcommand can be chosen by the user by setting
configuration options in .git/config (or ~/.gitconfig), as users may
want different expiration windows for each repository but shouldn't
be bothered to remember what they are all of the time.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

git-reflog: gc.* configuration and documentation.

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

rerere gc: honor configuration and document it

Two configuration to control the expiration of rerere records
are introduced and documented.

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

count-objects -v: show number of packs as well.

Recent "git push" keeps transferred objects packed much more aggressively
than before.  Monitoring output from git-count-objects -v for number of
loose objects is not enough to decide when to repack -- having too many
small packs is also a good cue for repacking.

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

Merge branch 'jc/fsck-reflog'

* jc/fsck-reflog:
  Add git-reflog to .gitignore
  reflog expire: do not punt on tags that point at non commits.
  reflog expire: prune commits that are not incomplete
  Don't crash during repack of a reflog with pruned commits.
  git reflog expire
  Move in_merge_bases() to commit.c
  reflog: fix warning message.
  Teach git-repack to preserve objects referred to by reflog entries.
  Protect commits recorded in reflog from pruning.
  add for_each_reflog_ent() iterator

everyday: update for v1.5.0

Fix minor mark-up mistakes and adjust to v1.5.0 BCP, namely:

 - use "git add" instead of "git update-index";
 - use "git merge" instead of "git pull .";
 - use separate remote layout;
 - use config instead of remotes/origin file;

Also updates "My typical git day" example since now I have
'next' branch these days.

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

git-svn: dcommit should diff against the current HEAD after committing

This is a followup to dd31da2fdc199132c9fd42023aea5b33672d73cc.
Regardless of whether we commit an alternate head, we always
diff-tree based on the current HEAD, and rebase against our
remote reference as necessary.

Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

git-svn: quiet down tests and fix some unportable shell constructs

The latest changes to git-commit have made it more verbose; and
I was running the setup of the tests outside of the test_expect_*,
so errors in those were not caught.  Now we move them to where
they can be eval'ed and have their output trapped.

export var=value has been removed

Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

hooks/commit-msg: add example to add Signed-off-by line to message

After checking to see if the commit message already has the target
signed-off-by (for example in --amend commits), this patch generates a
signed off by line from the repository owner and adds it to the commit
message.

Based on Johannes Schindelin's earlier patch to perform the same
function.

Originally, this was done in the pre-commit hook but Junio pointed out
that the commit-msg hook allows the message to be edited.  This has the
aditional advantage that the commit-msg hook gets passed the name of the
message file as a parameter, so it doesn't have to figure out GIT_DIR for
itself.

Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>

move git-blame to its place in .gitignore

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Add git-reflog to .gitignore

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

Teach log family --encoding

Updated commit objects record the encoding used in their
encoding header.  This updates the log family to reencode it
into the encoding specified in i18n.commitencoding (or the
default, which is "utf-8") upon output.

To force a specific encoding that is different, log family takes
command line flag --encoding=<encoding>; giving --encoding=none
entirely disables the reencoding and lets you view log messges
in their original encoding.

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

i18n.logToUTF8: convert commit log message to UTF-8

When i18n.commitencoding is set to a non UTF-8 encoding,
commit-tree records the encoding in an extra header after
author/committer headers in the commit object.

An earlier version used trailer but Johannes points out that
there is little risk breaking existing Porcelains with a new
header.

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

Move encoding conversion routine out of mailinfo to utf8.c

This moves the body of convert_to_utf8() routine used in mailinfo
to the utf8.c i18n library.

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

Document git-reset <commit> -- <paths>...

Document --numstat in git-apply and git-diff

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

show-branch --reflog: add documentation.

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

add .mailmap for git-shortlog output with the git repository

The git repository itself was messed up in a couple cases.

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>

GIT v1.5.0 preview

This is not yet -rc1 where all new topics closes, but I think it
is getting pretty closer.  I'd still want to merge updates to
fsck/prune to honor reflog entries before -rc1.

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

Merge branch 'jc/bm'

* jc/bm:
  Allow branch.*.merge to talk about remote tracking branches.

Merge branch 'rf/web'

* rf/web:
  gitweb: Use rev-list --skip option.
  gitweb: Change history action to use parse_commits.
  gitweb: Change atom, rss actions to use parse_commits.
  gitweb: Change header search action to use parse_commits.
  gitweb: Change log action to use parse_commits.
  gitweb: Change summary, shortlog actions to use parse_commits.
  gitweb: We do longer need the --parents flag in rev-list.
  gitweb: Add parse_commits, used to bulk load commit objects.

git-add -f: allow adding otherwise ignored files.

Instead of just warning, refuse to add otherwise ignored files
by default, and allow it with an -f option.

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

gitweb: Use rev-list --skip option.

Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

gitweb: Change history action to use parse_commits.

Also added missing accesskey.

Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

gitweb: Change atom, rss actions to use parse_commits.

Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

gitweb: Change header search action to use parse_commits.

Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

gitweb: Change log action to use parse_commits.

Also add missing next link to bottom of page.

Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

gitweb: Change summary, shortlog actions to use parse_commits.

Also added missing accesskey.

Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

gitweb: We do longer need the --parents flag in rev-list.

We only want to know the direct parents of a given commit object,
these parents are available in the --header output of rev-list.  If
--parents is supplied with --full-history the output includes merge
commits that aren't relevant.

Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

gitweb: Add parse_commits, used to bulk load commit objects.

Add a new method parse_commits which is able to parse multiple commit
objects at once.  Reworked parse_commit to share the commit object
parsing logic.

Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

git-add: warn when adding an ignored file with an explicit request.

We allow otherwise ignored paths to be added to the index by
spelling its path out on the command line, but we would warn the
user about them when we do so.

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

git-add: add ignored files when asked explicitly.

One thing many people found confusing about git-add was that a
file whose name matches an ignored pattern could not be added to
the index.  With this, such a file can be added by explicitly
spelling its name to git-add.

Fileglobs and recursive behaviour do not add ignored files to
the index.  That is, if a pattern '*.o' is in .gitignore, and
two files foo.o, bar/baz.o are in the working tree:

    $ git add foo.o
    $ git add '*.o'
    $ git add bar

Only the first form adds foo.o to the index.

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

read_directory: show_both option.

This teaches the internal read_directory() routine to return
both interesting and ignored pathnames.

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

git-rm: Documentation

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

t3600: update the test for updated git rm

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

git-rm: update to saner semantics

This updates the "git rm" command with saner semantics suggested
on the list earlier with:

Message-ID: <Pine.LNX.4.64.0612020919400.3476@woody.osdl.org>
Message-ID: <Pine.LNX.4.64.0612040737120.3476@woody.osdl.org>

The command still validates that the given paths all talk about
sensible paths to avoid mistakes (e.g. "git rm fiel" when file
"fiel" does not exist would error out -- user meant to remove
"file"), and it has further safety checks described next.  The
biggest difference is that the paths are removed from both index
and from the working tree (if you have an exotic need to remove
paths only from the index, you can use the --cached option).

The command refuses to remove if the copy on the working tree
does not match the index, or if the index and the HEAD does not
match.  You can defeat this check with -f option.

This safety check has two exceptions: if the working tree file
does not exist to begin with, that technically does not match
the index but it is allowed.  This is to allow this CVS style
command sequence:

rm <path> && git rm <path>

Also if the index is unmerged at the <path>, you can use "git rm
<path>" to declare that the result of the merge loses that path,
and the above safety check does not trigger; requiring the file
to match the index in this case forces the user to do "git
update-index file && git rm file", which is just crazy.

To recursively remove all contents from a directory, you need to
pass -r option, not just the directory name as the <path>.

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

match_pathspec() -- return how well the spec matched

This updates the return value from match_pathspec() so that the
caller can tell cases between exact match, leading pathname
match (i.e. file "foo/bar" matches a pathspec "foo"), or
filename glob match.  This can be used to prevent "rm dir" from
removing "dir/file" without explicitly asking for recursive
behaviour with -r flag, for example.

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

Merge branch 'jc/skip-count'

* jc/skip-count:
  revision: --skip=<n>

Merge branch 'jc/git-add--interactive'

* jc/git-add--interactive:
  git-add --interactive: add documentation
  git-add --interactive: hunk splitting
  git-add --interactive

git-add --interactive: add documentation

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

Allow branch.*.merge to talk about remote tracking branches.

People often get confused if the value of branch.*.merge should
be the remote branch name they are fetching from, or the
tracking branch they locally have.  So this allows either.

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