I found I needed NI_MAXSERV as it is defined in netdb.h, which is
not included by daemon.c.  Rather than including the whole header
we can define a reasonable fallback value.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

CVS gets understandably upset if you try and add a subdirectory
before it's parent directory. This patch fixes that.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Ok, what is going on is:

 - append_fetch_head() looks up the SHA1 for all heads (including tags):

        if (get_sha1(head, sha1))
                return error("Not a valid object name: %s", head);

 - it then wants to check if it's a candidate for merging (because
   fetching also does the whole "list which heads to merge" in case
   it is going to be part of a "pull"):

        commit = lookup_commit_reference(sha1);
        if (!commit)
                not_for_merge = 1;

 - and that "lookup_commit_reference()" is just very vocal about the
   case where it fails. It really shouldn't be, and it shouldn't
   affect the actual end result, but that basically explains why
   you get that scary warning.

In short, the warning is just bogus, and should be harmless, but
I agree that it's ugly. I think the appended patch should fix it.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

This was causing test failures because die was exiting 255.
Signed-off-by: NBrian Gernhardt <benji@silverinsanity.com>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

If we are in the middle of resolving a merge conflict there may be
one or more files whose entries in the index represent an unmerged
state (index entries in the higher-order stages).

Attempting to run git-blame on any file in such a working directory
resulted in "fatal: internal error: ce_mode is 0" as we use the magic
marker for an unmerged entry is 0 (set up by things like diff-lib.c's
do_diff_cache() and builtin-read-tree.c's read_tree_unmerged())
and the ce_match_stat_basic() function gets upset about this.

I'm not entirely sure that the whole "ce_mode = 0" case is a good
idea to begin with, and maybe the right thing to do is to remove
that horrid freakish special case, but removing the internal error
seems to be the simplest fix for now.

                Linus

[sp: Thanks to Björn Steinbrink for the test case]
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Instead of simply exiting with 255, print an error message including
the reason why a config file specified through --file cannot be opened
or read.

The problem was noticed by Joey Hess, reported through
 http://bugs.debian.org/445208Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

post-receive-email has one place where the variable fast_forward is not
spelled correctly.  At the same place the logic was reversed.  The
combination of both bugs made the script work correctly for fast-forward
commits but not for non-fast-forward ones.  This change fixes this to
be correct in both cases.
Signed-off-by: NRobert Schiele <rschiele@gmail.com>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

This fixes git-instaweb so it can start an httpd without warning
about an invalid test command.  Yes its ugly, but its also quite
portable.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Earlier, "git filter-branch --<options> HEAD" would not update the
working tree after rewriting the branch.  This commit fixes it.
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

The man page for filter-branch still talked about writing the result
to the branch "newbranch".  This is hopefully the last place where the
old behaviour was described.

Noticed by Bill Lear.
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Signed-off-by: NAndrew Clausen <clausen@econ.upenn.edu>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

There are a few programs, such as config and diff, which allow running
without a git repository.  Therefore, they have to call
setup_git_directory_gently().

However, when GIT_DIR and GIT_WORK_TREE were set, and the current
directory was a subdirectory of the work tree,
setup_git_directory_gently() would return a bogus NULL prefix.

This patch fixes that.

Noticed by REPLeffect on IRC.
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Noticed by Michele Ballabio.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

When diff drivers are installed, calling "git diff <tree1>..<tree2>"
calls those drivers.  This borks the patch generation of rebase -i.
So use "git diff-tree -p" instead, which does not call diff drivers.

Noticed by Johannes Sixt.
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NLars Hjemli <hjemli@gmail.com>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Before this patch the clean target has removed the
configure script that comes with Git tar file.
That made compiling Git for different architectures
inconvenient.
This patch excludes configure from the files to be
deleted by 'make clean' and adds new target 'distclean'
to preserve old functionality.
Signed-off-by: NMathias Megyei <mathias@mnet-mail.de>
Signed-off-by: NLars Hjemli <hjemli@gmail.com>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Signed-off-by: NMichele Ballabio <barra_cuda@katamail.com>
Signed-off-by: NLars Hjemli <hjemli@gmail.com>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Signed-off-by: NMichele Ballabio <barra_cuda@katamail.com>
Signed-off-by: NLars Hjemli <hjemli@gmail.com>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

When calling git-config not from the top level directory of a repository,
it changes directory before trying to open the config file specified
through the --file option, which then fails if the config file was
specified by a relative pathname.  This patch adjusts the pathname to
the config file if applicable.

The problem was noticed by Joey Hess, reported through
 http://bugs.debian.org/445208Signed-off-by: NGerrit Pape <pape@smarden.org>
Signed-off-by: NLars Hjemli <hjemli@gmail.com>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Before this patch, clear_commit_marks() recursed for each parent.  This
could be potentially very expensive in terms of stack space.  Probably
the only reason that this did not lead to problems is the fact that we
typically call clear_commit_marks() after marking a relatively small set
of commits.

Use (sort of) a tail recursion instead: first recurse on the parents
other than the first one, and then continue the loop with the first
parent.

Noticed by Shawn Pearce.
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NLars Hjemli <hjemli@gmail.com>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Signed-off-by: NJean-Luc Herren <jlh@gmx.ch>
Signed-off-by: NLars Hjemli <hjemli@gmail.com>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

The unified diff format allows one-line ranges to be abbreviated
by omiting the size.  The hunk header "@@ -10,1 +10,1 @@" can be
expressed as "@@ -10 +10 @@", but this wasn't properly parsed in
all cases.

Such abbreviated hunk headers are generated when a one-line change
(add, remove or modify) appears without context; for example
because the file is a one-liner itself or because GIT_DIFF_OPTS
was set to '-u0'.  If the user then runs 'git add -i' and enters
the 'patch' command for that file, perl complains about undefined
variables.
Signed-off-by: NJean-Luc Herren <jlh@gmx.ch>
Signed-off-by: NLars Hjemli <hjemli@gmail.com>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Error out if someone gives options after --list since that is
not a valid syntax.
Signed-off-by: NFrank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: NLars Hjemli <hjemli@gmail.com>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

This fixes an unnecessary empty line that we add to the log message when
we generate diffs, but don't actually end up printing any due to having
DIFF_FORMAT_NO_OUTPUT set.

This can happen with pickaxe or with rename following. The reason is that
we normally add an empty line between the commit and the diff, but we do
that even for the case where we've then suppressed the actual printing of
the diff.

This also updates a couple of tests that assumed the extraneous empty
line would exist at the end of output.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NLars Hjemli <hjemli@gmail.com>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

It turns out that I completely broke "git log --follow" with my recent
patch to revision.c ("Fix revision log diff setup, avoid unnecessary diff
generation", commit b7bb760d).

Why? Because --follow obviously requires the diff machinery to function,
exactly the same way pickaxe does.

So everybody is away right now, but considering that nobody even noticed
this bug, I don't think it matters. But for the record, here's the trivial
one-liner fix (well, two, since I also fixed the comment).

Because of the nature of the bug, if you ask for patches when following
(which is one of the things I normally do), the bug is hidden, because
then the request for diff output will automatically also enable the diffs
themselves.

So while "git log --follow <filename>" didn't work, adding a "-p"
magically made it work again even without this fix.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NLars Hjemli <hjemli@gmail.com>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This tests basic functionality and also exercises a bug noticed
by Keith Packard, (prune_cache followed by add_index_entry can
trigger an attempt to realloc a pointer into the middle of an
allocated buffer).
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The index cache is not static, growing as new entries are added. If
entries are added after prune_cache is called, cache will no longer
point at the base of the allocation, and realloc will not be happy.

I verified that this was the only place in the current source which
modified any index_state.cache elements aside from the alloc/realloc
calls in read-cache by changing the type of the element to 'struct
cache_entry ** const cache' and recompiling.

A more efficient patch would create a separate 'cache_base' value to
track the allocation and then fix things up when reallocation was
necessary, instead of the brute-force memmove used here.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Some systems that have only installed the GNU toolchain (prefixed with "g")
do not provide "ar" but only "gar".  Make configure find this tool as well.
Signed-off-by: NRobert Schiele <rschiele@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJunio C Hamano <gitster@pobox.com>

We find rename candidates by computing a fingerprint hash of
each file, and then comparing those fingerprints. There are
inherently O(n^2) comparisons, so it pays in CPU time to
hoist the (rather expensive) computation of the fingerprint
out of that loop (or to cache it once we have computed it once).

Previously, we didn't keep the filespec information around
because then we had the potential to consume a great deal of
memory. However, instead of keeping all of the filespec
data, we can instead just keep the fingerprint.

This patch implements and uses diff_free_filespec_data_large
to accomplish that goal. We also have to change
estimate_similarity not to needlessly repopulate the
filespec data when we already have the hash.

Practical tests showed 4.5x speedup for a 10% memory usage
increase.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NJohan Herland <johan@herland.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NFederico Mena Quintero <federico@gnu.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NFederico Mena Quintero <federico@gnu.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NFederico Mena Quintero <federico@gnu.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The documentation used to say what the option does, but it
didn't mention a use case.
Signed-off-by: NFederico Mena Quintero <federico@gnu.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

There was an 'l' (ell) instead of a '1' (one) in one of the gitlinks.
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The string value of %(numparent) was not returned correctly.
Also %(parent) misbehaved for the root commits (returned garbage)
and merge commits (returned first parent, followed by a space).
Signed-off-by: NJunio C Hamano <gitster@pobox.com>