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>

We rely on TMP_INDEX variable to decide if we are doing a partial commit,
as it is only set in the partial commit codepath.  But the variable is
never initialized.  A stray environment variable from outside could
ruin the day.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NSteffen Prohaska <prohaska@zib.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

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

post-receive-hook: Remove the From field from the generated email header so that the pusher's name is used

Using the name of the committer of the revision at the tip of the
updated ref is not sensible.  That information is available in the email
itself should it be wanted, and by supplying a "From", we were
effectively hiding the person who performed the push - which is useful
information in itself.
Signed-off-by: NAndy Parkins <andyparkins@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Some subcommands of "git-remote" detected and issued error
messages but did not signal that to the calling process with
exit status.
Signed-off-by: NJari Aalto <jari.aalto@cante.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

It was determined on the mailing list, that it makes more sense for a
"squash" to keep the author of the first commit as the author for the
result of the squash.

Make it so.
Signed-off-by: NJohannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

1) Previously, any menu would cause a perl error when entered '0',
   which is never a valid option.

2) Entering a bogus choice (like 998 or 4-2) surprisingly caused
   the same behavior as if the user had just hit 'enter', which
   means to carry out the selected action on the selected items.
   Entering such bogus input is now a no-op and the sub-menu
   doesn't exit.
Signed-off-by: NJean-Luc Herren <jlh@gmx.ch>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Hitting Ctrl-D (EOF) is a common way to exit shell-like tools.
When in a sub-menu it will still behave as if an empty line had
been entered, carrying out the action on the selected items and
returning to the previous menu.
Signed-off-by: NJean-Luc Herren <jlh@gmx.ch>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

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

We used to incorrectly start calculating diffs whenever any argument but
'-z' was recognized by the diff options parsing. That was bogus, since not
all arguments result in diffs being needed, so we just waste a lot of time
and effort on calculating diffs that don't matter.

This actually also fixes another bug in "git log". Try this:

	git log -C

and notice how it prints an extra empty line in between log entries, even
though it never prints the actual diff (because we didn't ask for any diff
format, so the diff machinery never prints anything).

With this patch, that bogus empty line is gone, because "revs->diff" is
never set.  So this isn't just a "wasted time and effort" issue, it's also
a slight semantic fix.
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Multiple commands were displayed in one line, making the manpage hard to read.
Signed-off-by: NMiklos Vajna <vmiklos@frugalware.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

* 'mergetool' of git://repo.or.cz/git/mergetool:
  mergetool: Fix typo in options passed to kdiff3
  mergetool: fix emerge when running in a subdirectory
  Mergetool generating blank files (1.5.3)

Fix missing double hyphens in "-L1" and "-L2"
Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>

Only pass the basename of the output filename when to emerge, since
emerge interprets non-absolute pathnames relative to the containing
directory of the output buffer.

Thanks to Kelvie Wong for pointing this out.
Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>

When mergetool is run from a subdirectory, "ls-files -u" nicely
limits the output to conflicted files in that directory, but
we need to give the full path to cat-file plumbing to grab the
contents of stages.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>

When quiltimport encounters a non-existent patch in the series file,
just skip to the next patch. This matches the behavior of quilt.
Signed-off-by: NDan Nicholson <dbn.lists@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>