cvsexportcommit: fix for commits that do not have parents

Previously commits without parents would fail to export with a
message indicating that the commits had more than one parent.
Instead we should use the --root option for git-diff-tree in
place of a parent.

Signed-off-by: Brad King <brad.king@kitware.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

GIT 1.5.3.5

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

Update GIT 1.5.3.5 Release Notes

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

git-rebase--interactive.sh: Make 3-way merge strategies work for -p.

git-rebase--interactive.sh used to pass all parents of a merge commit to
git-merge, which means that we have at least 3 heads to merge: HEAD,
first parent and second parent. So 3-way merge strategies like recursive
wouldn't work.

Fortunately, we have checked out the first parent right before the merge
anyway, so that is HEAD. Therefore we can drop simply it from the list
of parents, making 3-way strategies work for merge commits with only
two parents.

Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-rebase--interactive.sh: Don't pass a strategy to git-cherry-pick.

git-cherry-pick doesn't support a strategy paramter, so don't pass one.
This means that --strategy for interactive rebases is a no-op for
anything but merge commits, but that's still better than being broken. A
correct fix would probably need to port the --merge behaviour from plain
git-rebase.sh, but I have no clue how to integrate that cleanly.

Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fix --strategy parsing in git-rebase--interactive.sh

For the --strategy/-s option, git-rebase--interactive.sh dropped the
parameter which it was trying to parse.

Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Make merge-recursive honor diff.renamelimit

It might be a sign of source code management gone bad, but when two branches
has diverged almost beyond recognition and time has come for the branches to
merge, the user is going to need all the help his tool can give him. Honoring
diff.renamelimit has great potential as a painkiller in such situations.

The painkiller effect could have been achieved by e.g. 'merge.renamelimit',
but the flexibility gained by a separate option is questionable: our user
would probably expect git to detect renames equally good when merging as
when diffing (I known I did).

Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

cherry-pick/revert: more compact user direction message

A failed cherry-pick (and friend) currently says:

|Automatic cherry-pick failed.  After resolving the conflicts,
|mark the corrected paths with 'git-add <paths>'
|and commit the result.

This can obviously be displayed on two lines only.
While at it, change "git-add" to "git add".

Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

core-tutorial: Use new syntax for git-merge.

"git-merge <msg> HEAD <other branches>" is still supported but
we shouldn't encourage its use.

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

git-merge: document but discourage the historical syntax

Historically "git merge" took its command line arguments in a
rather strange order.  Document the historical syntax, and also
document clearly that it is not encouraged in new scripts.

There is no reason to deprecate the historical syntax, as the
current code can sanely tell which syntax the caller is using,
and existing scripts by people do use the historical syntax.

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

Prevent send-pack from segfaulting (backport from 'master')

4491e62ae932d5774f628d1bd3be663c11058a73 (Prevent send-pack from
segfaulting when a branch doesn't match) is hereby cherry-picked
back to 'maint'.

If we can't find a source match, and we have no destination, we
need to abort the match function early before we try to match
the destination against the remote.

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

Documentation/git-cvsexportcommit.txt: s/mgs/msg/ in example

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

RelNotes-1.5.3.5: describe recent fixes

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

merge-recursive.c: mrtree in merge() is not used before set

The called function merge_trees() sets its *result, to which the
address of the variable mrtree in merge() function is passed,
only when index_only is set.  But that is Ok as the function
uses the value in the variable only under index_only iteration.

However, recent gcc does not realize this.  Work it around by
adding a fake initializer.

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

sha1_file.c: avoid gcc signed overflow warnings

With the recent gcc, we get:

sha1_file.c: In check_packed_git_:
sha1_file.c:527: warning: assuming signed overflow does not
occur when assuming that (X + c) < X is always false
sha1_file.c:527: warning: assuming signed overflow does not
occur when assuming that (X + c) < X is always false

for a piece of code that tries to make sure that off_t is large
enough to hold more than 2^32 offset.  The test tried to make
sure these do not wrap-around:

    /* make sure we can deal with large pack offsets */
    off_t x = 0x7fffffffUL, y = 0xffffffffUL;
    if (x > (x + 1) || y > (y + 1)) {

but gcc assumes it can do whatever optimization it wants for a
signed overflow (undefined behaviour) and warns about this
construct.

Follow Linus's suggestion to check sizeof(off_t) instead to work
around the problem.

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

Fix a small memory leak in builtin-add

prune_directory and fill_directory allocated one byte per pathspec and never
freed it.

Signed-off-by: Benoit Sigoure <tsuna@lrde.epita.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

honor the http.sslVerify option in shell scripts

Signed-off-by: Aurélien Bompard <aurelien@bompard.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fix generation of perl/perl.mak

The code generating perl/Makefile from Makefile.PL was causing trouble
because it didn't considered NO_PERL_MAKEMAKER and ran makemaker
unconditionally, rewriting perl.mak. Makemaker is FUBAR in ActiveState Perl,
and perl/Makefile has a replacement for it.

Besides, a changed Git.pm is *NOT* a reason to rebuild all the perl scripts,
so remove the dependency too.

Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-remote: fix "Use of uninitialized value in string ne"

martin f krafft <madduck@madduck.net> writes:

> piper:~> git remote show origin
> * remote origin
>   URL: ssh://git.madduck.net/~/git/etc/mailplate.git
> Use of uninitialized value in string ne at /usr/local/stow/git/bin/git-remote line 248.

This is because there might not be branch.<name>.remote defined but
the code unconditionally dereferences $branch->{$name}{'REMOTE'} and
compares with another string.

Tested-by: Martin F Krafft <madduck@madduck.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Describe more 1.5.3.5 fixes in release notes

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

Fix diffcore-break total breakage

Ok, so on the kernel list, some people noticed that "git log --follow"
doesn't work too well with some files in the x86 merge, because a lot of
files got renamed in very special ways.

In particular, there was a pattern of doing single commits with renames
that looked basically like

 - rename "filename.h" -> "filename_64.h"
 - create new "filename.c" that includes "filename_32.h" or
   "filename_64.h" depending on whether we're 32-bit or 64-bit.

which was preparatory for smushing the two trees together.

Now, there's two issues here:

 - "filename.c" *remained*. Yes, it was a rename, but there was a new file
   created with the old name in the same commit. This was important,
   because we wanted each commit to compile properly, so that it was
   bisectable, so splitting the rename into one commit and the "create
   helper file" into another was *not* an option.

   So we need to break associations where the contents change too much.
   Fine. We have the -B flag for that. When we break things up, then the
   rename detection will be able to figure out whether there are better
   alternatives.

 - "git log --follow" didn't with with -B.

Now, the second case was really simple: we use a different "diffopt"
structure for the rename detection than the basic one (which we use for
showing the diffs). So that second case is trivially fixed by a trivial
one-liner that just copies the break_opt values from the "real" diffopts
to the one used for rename following. So now "git log -B --follow" works
fine:

diff --git a/tree-diff.c b/tree-diff.c
index 26bdbdd..7c261fd 100644
--- a/tree-diff.c
+++ b/tree-diff.c
@@ -319,6 +319,7 @@ static void try_to_follow_renames(struct tree_desc *t1, struct tree_desc *t2, co
  diff_opts.detect_rename = DIFF_DETECT_RENAME;
  diff_opts.output_format = DIFF_FORMAT_NO_OUTPUT;
  diff_opts.single_follow = opt->paths[0];
+ diff_opts.break_opt = opt->break_opt;
  paths[0] = NULL;
  diff_tree_setup_paths(paths, &diff_opts);
  if (diff_setup_done(&diff_opts) < 0)

however, the end result does *not* work. Because our diffcore-break.c
logic is totally bogus!

In particular:

 - it used to do

if (base_size < MINIMUM_BREAK_SIZE)
return 0; /* we do not break too small filepair */

   which basically says "don't bother to break small files". But that
   "base_size" is the *smaller* of the two sizes, which means that if some
   large file was rewritten into one that just includes another file, we
   would look at the (small) result, and decide that it's smaller than the
   break size, so it cannot be worth it to break it up! Even if the other
   side was ten times bigger and looked *nothing* like the samell file!

   That's clearly bogus. I replaced "base_size" with "max_size", so that
   we compare the *bigger* of the filepair with the break size.

 - It calculated a "merge_score", which was the score needed to merge it
   back together if nothing else wanted it. But even if it was *so*
   different that we would never want to merge it back, we wouldn't
   consider it a break! That makes no sense. So I added

if (*merge_score_p > break_score)
return 1;

   to make it clear that if we wouldn't want to merge it at the end, it
   was *definitely* a break.

 - It compared the whole "extent of damage", counting all inserts and
   deletes, but it based this score on the "base_size", and generated the
   damage score with

delta_size = src_removed + literal_added;
damage_score = delta_size * MAX_SCORE / base_size;

   but that makes no sense either, since quite often, this will result in
   a number that is *bigger* than MAX_SCORE! Why? Because base_size is
   (again) the smaller of the two files we compare, and when you start out
   from a small file and add a lot (or start out from a large file and
   remove a lot), the base_size is going to be much smaller than the
   damage!

   Again, the fix was to replace "base_size" with "max_size", at which
   point the damage actually becomes a sane percentage of the whole.

With these changes in place, not only does "git log -B --follow" work for
the case that triggered this in the first place, ie now

git log -B --follow arch/x86/kernel/vmlinux_64.lds.S

actually gives reasonable results. But I also wanted to verify it in
general, by doing a full-history

git log --stat -B -C

on my kernel tree with the old code and the new code.

There's some tweaking to be done, but generally, the new code generates
much better results wrt breaking up files (and then finding better rename
candidates). Here's a few examples of the "--stat" output:

 - This:
include/asm-x86/Kbuild        |    2 -
include/asm-x86/debugreg.h    |   79 +++++++++++++++++++++++++++++++++++------
include/asm-x86/debugreg_32.h |   64 ---------------------------------
include/asm-x86/debugreg_64.h |   65 ---------------------------------
4 files changed, 68 insertions(+), 142 deletions(-)

      Becomes:

include/asm-x86/Kbuild                        |    2 -
include/asm-x86/{debugreg_64.h => debugreg.h} |    9 +++-
include/asm-x86/debugreg_32.h                 |   64 -------------------------
3 files changed, 7 insertions(+), 68 deletions(-)

 - This:
include/asm-x86/bug.h    |   41 +++++++++++++++++++++++++++++++++++++++--
include/asm-x86/bug_32.h |   37 -------------------------------------
include/asm-x86/bug_64.h |   34 ----------------------------------
3 files changed, 39 insertions(+), 73 deletions(-)

      Becomes

include/asm-x86/{bug_64.h => bug.h} |   20 +++++++++++++-----
include/asm-x86/bug_32.h            |   37 -----------------------------------
2 files changed, 14 insertions(+), 43 deletions(-)

Now, in some other cases, it does actually turn a rename into a real
"delete+create" pair, and then the diff is usually bigger, so truth in
advertizing: it doesn't always generate a nicer diff. But for what -B was
meant for, I think this is a big improvement, and I suspect those cases
where it generates a bigger diff are tweakable.

So I think this diff fixes a real bug, but we might still want to tweak
the default values and perhaps the exact rules for when a break happens.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Fix directory scanner to correctly ignore files without d_type

On Fri, 19 Oct 2007, Todd T. Fries wrote:
> If DT_UNKNOWN exists, then we have to do a stat() of some form to
> find out the right type.

That happened in the case of a pathname that was ignored, and we did
not ask for "dir->show_ignored". That test used to be *together*
with the "DTYPE(de) != DT_DIR", but splitting the two tests up
means that we can do that (common) test before we even bother to
calculate the real dtype.

Of course, that optimization only matters for systems that don't
have, or don't fill in DTYPE properly.

I also clarified the real relationship between "exclude" and
"dir->show_ignored". It used to do

if (exclude != dir->show_ignored) {
..

which wasn't exactly obvious, because it triggers for two different
cases:

 - the path is marked excluded, but we are not interested in ignored
   files: ignore it

 - the path is *not* excluded, but we *are* interested in ignored
   files: ignore it unless it's a directory, in which case we might
   have ignored files inside the directory and need to recurse
   into it).

so this splits them into those two cases, since the first case
doesn't even care about the type.

I also made a the DT_UNKNOWN case a separate helper function,
and added some commentary to the cases.

Linus

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

Merge branch 'maint' of git://repo.or.cz/git-gui into maint

* 'maint' of git://repo.or.cz/git-gui:
  git-gui: Don't display CR within console windows
  git-gui: Handle progress bars from newer gits
  git-gui: Correctly report failures from git-write-tree
  git-gui: accept versions containing text annotations, like 1.5.3.mingw.1
  git-gui: Don't crash when starting gitk from a browser session
  git-gui: Allow gitk to be started on Cygwin with native Tcl/Tk
  git-gui: Ensure .git/info/exclude is honored in Cygwin workdirs
  git-gui: Handle starting on mapped shares under Cygwin
  git-gui: Display message box when we cannot find git in $PATH
  git-gui: Avoid using bold text in entire gui for some fonts

Improve receive-pack error message about funny ref creation

receive-pack is only executed remotely so when
reporting errors, say so.

Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

fast-import: Fix argument order to die in file_change_m

The arguments to the "Not a blob" die call in file_change_m were
transposed, so that the command was printed as the type, and the type
as the command.  Switch them around so that the error message comes
out correctly.

Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: Don't display CR within console windows

Git progress bars from tools like git-push and git-fetch use CR
to skip back to the start of the current line and redraw it with
an updated progress.  We were doing this in our Tk widget but had
failed to skip the CR, which Tk doesn't draw well.

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

git-gui: Handle progress bars from newer gits

Post Git 1.5.3 a new style progress bar has been introduced that
uses only one line rather than two.  The formatting of the completed
and total section is also slightly different so we must adjust our
regexp to match.  Unfortunately both styles are in active use by
different versions of Git so we need to look for both.

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

git-gui: Correctly report failures from git-write-tree

If git-write-tree fails (such as if the index file is currently
locked and it wants to write to it) we were not getting the error
message as $tree_id was always the empty string so we shortcut
through the catch and never got the output from stderr.

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

gitk.txt: Fix markup.

For the manpage, avoid generating an em dash in code.

Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

send-pack: respect '+' on wildcard refspecs

When matching source and destination refs, we were failing
to pull the 'force' parameter from wildcard refspecs (but
not explicit ones) and attach it to the ref struct.

This adds a test for explicit and wildcard refspecs; the
latter fails without this patch.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Paper bag fix diff invocation in 'git stash show'

In 89d750bf6fa025edeb31ad258cdd09a27a5c02fa I got a little too
aggressive with changing "git diff" to "git diff-tree".  This is
shown to the user, who expects to see a full diff on their console,
and will want to see the output of their custom diff drivers (if
any) as the whole point of this call site is to show the diff to
the end-user.

Noticed by Johannes Sixt <j.sixt@viscovery.net>.

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

Further 1.5.3.5 fixes described in release notes

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

Avoid invoking diff drivers during git-stash

git-stash needs to restrict itself to plumbing when running automated
diffs as part of its operation as the user may have configured a
custom diff driver that opens an interactive UI for certain/all
files.  Doing that during scripted actions is very unfriendly to
the end-user and may cause git-stash to fail to work.

Reported by Johannes Sixt

Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

attr: fix segfault in gitattributes parsing code

git may segfault if gitattributes contains an invalid
entry. A test is added to t0020 that triggers the segfault.
The parsing code is fixed to avoid the crash.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Define NI_MAXSERV if not defined by operating system

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: Shawn O. Pearce <spearce@spearce.org>

Ensure we add directories in the correct order

CVS gets understandably upset if you try and add a subdirectory
before it's parent directory. This patch fixes that.

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

Avoid scary errors about tagged trees/blobs during git-fetch

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: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Yet more 1.5.3.5 fixes mentioned in release notes

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

cvsserver: Use exit 1 instead of die when req_Root fails.

This was causing test failures because die was exiting 255.

Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-blame shouldn't crash if run in an unmerged tree

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: Shawn O. Pearce <spearce@spearce.org>

git-config: print error message if the config file cannot be read

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/445208

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

fixing output of non-fast-forward output of post-receive-email

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: Robert Schiele <rschiele@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Document additional 1.5.3.5 fixes in release notes

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

Avoid 'expr index' on Mac OS X as it isn't supported

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: Shawn O. Pearce <spearce@spearce.org>

filter-branch: update current branch when rewritten

Earlier, "git filter-branch --<options> HEAD" would not update the
working tree after rewriting the branch.  This commit fixes it.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

fix filter-branch documentation

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: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

helpful error message when send-pack finds no refs in common.

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

Fix setup_git_directory_gently() with relative GIT_DIR & GIT_WORK_TREE

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: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Correct typos in release notes for 1.5.3.5

Noticed by Michele Ballabio.

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

Whip post 1.5.3.4 maintenance series into shape.

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

rebase -i: use diff plumbing instead of porcelain

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: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Do not remove distributed configure script

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: Mathias Megyei <mathias@mnet-mail.de>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-archive: document --exec

Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-reflog: document --verbose

Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-config: handle --file option with relative pathname properly

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/445208

Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

clear_commit_marks(): avoid deep recursion

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: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git add -i: Remove unused variables

Signed-off-by: Jean-Luc Herren <jlh@gmx.ch>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git add -i: Fix parsing of abbreviated hunk headers

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: Jean-Luc Herren <jlh@gmx.ch>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-config: don't silently ignore options after --list

Error out if someone gives options after --list since that is
not a valid syntax.

Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Clean up "git log" format with DIFF_FORMAT_NO_OUTPUT

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: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Fix embarrassing "git log --follow" bug

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 b7bb760d5ed4881422673d32f869d140221d3564).

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: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

git-gui: accept versions containing text annotations, like 1.5.3.mingw.1

This commit teaches git-gui to accept versions with annotations
that start with text and optionally end with a dot followed by
a number.

This is needed by the current versioning scheme of msysgit,
which uses versions like 1.5.3.mingw.1. However, the changes
is not limited to this use case. Any version of the form
<numeric version>.<anytext>.<number> would be parsed and only
the starting <numeric version> used for validation.

[sp: Minor edit to remove unnecessary group matching]

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

GIT 1.5.3.4

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

Add test case for ls-files --with-tree

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: Junio C Hamano <gitster@pobox.com>

Must not modify the_index.cache as it may be passed to realloc at some point.

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: Junio C Hamano <gitster@pobox.com>

git-gui: Don't crash when starting gitk from a browser session

If the user has started git-gui from the command line as a browser
we offer the gitk menu options but we didn't create the main status
bar widget in the "." toplevel.  Trying to access it while starting
gitk just results in Tcl errors.

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

git-gui: Allow gitk to be started on Cygwin with native Tcl/Tk

gitk expects $env(GIT_DIR) to be valid as both a path that core Git
and Tcl/Tk can resolve to a valid directory, but it has no special
handling for Cygwin style UNIX paths and Windows style paths.  So
we need to do that for gitk and ensure that only relative paths are
fed to it, thus allowing both Cygwin style and UNIX style paths to
be resolved.

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

the ar tool is called gar on some systems

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: Robert Schiele <rschiele@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

rename diff_free_filespec_data_large() to diff_free_filespec_blob()

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

diffcore-rename: cache file deltas

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: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Mention 'cpio' dependency in INSTALL

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

Make git-pull complain and give advice when there is nothing to merge with

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

Note that git-branch will not automatically checkout the new branch

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

Add documentation for --track and --no-track to the git-branch docs.

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

Say when --track is useful in the git-checkout docs.

The documentation used to say what the option does, but it
didn't mention a use case.

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

Fix typo in config.txt

There was an 'l' (ell) instead of a '1' (one) in one of the gitlinks.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

for-each-ref: fix %(numparent) and %(parent)

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: Junio C Hamano <gitster@pobox.com>

git-commit: initialize TMP_INDEX just to be sure.

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: Junio C Hamano <gitster@pobox.com>

fixed link in documentation of diff-options

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

Whip post 1.5.3.3 maintenance series into shape.

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

git stash: document apply's --index switch

Signed-off-by: Junio 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: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-remote: exit with non-zero status after detecting errors.

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: Jari Aalto <jari.aalto@cante.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

rebase -i: squash should retain the authorship of the _first_ commit

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: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-add--interactive: Improve behavior on bogus input

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: Jean-Luc Herren <jlh@gmx.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-add--interactive: Allow Ctrl-D to exit

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: Jean-Luc Herren <jlh@gmx.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

GIT 1.5.3.3

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

Fix revision log diff setup, avoid unnecessary diff generation

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: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

git-bundle: fix commandline examples in the manpage

Multiple commands were displayed in one line, making the manpage hard to read.

Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Merge branch 'mergetool' of git://repo.or.cz/git/mergetool into maint

* '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)

mergetool: Fix typo in options passed to kdiff3

Fix missing double hyphens in "-L1" and "-L2"

Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>

mergetool: fix emerge when running in a subdirectory

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: "Theodore Ts'o" <tytso@mit.edu>

Mergetool generating blank files (1.5.3)

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: Junio C Hamano <gitster@pobox.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>

quiltimport: Skip non-existent patches

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: Dan Nicholson <dbn.lists@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

apply: get rid of --index-info in favor of --build-fake-ancestor

git-am used "git apply -z --index-info" to find the original versions
of the files touched by the diff, to be able to do an inexpensive
three-way merge.

This operation makes only sense in a repository, since the index
information in the diff refers to blobs, which have to be present in
the current repository.

Therefore, teach "git apply" a mode to write out the result as an
index file to begin with, obviating the need for scripts to do it
themselves.

The sole user for --index-info is "git am" is converted to
use --build-fake-ancestor in this patch.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Move make_cache_entry() from merge-recursive.c into read-cache.c

The function make_cache_entry() is too useful to be hidden away in
merge-recursive.  So move it to libgit.a (exposing it via cache.h).

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

core-tutorial: correct URL

The tinyurl is incorrect -- it attempts to go to groups.osdl.org,
which is gone.  Either use the full URL (in patch) or create a new
tinyurl for this URL.

Is the web page (where I first saw this problem) generated from
this txt file?
http://www.kernel.org/pub/software/scm/git/docs/core-tutorial.html
If not, it needs to be updated also.

Signed-off-by: Randy Dunlap <rdunlap@xenotime.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

Fix spelling of overridden in documentation

Signed-off-by: Shawn Bohrer <shawn.bohrer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitattributes.txt: Be more to the point in the filter driver description.

The description was meant to emphasizes that the project should remain
usable even if the filter driver was not used. This makes it more explicit
and removes the "here is rope to hang yourself" paraphrase.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

gitattributes.txt: Remove a duplicated paragraph about 'ident' and 'crlf' interaction.

The order in which 'ident' and 'crlf' are carried out is documented a few paragraphs
later again, after 'filter' was introduced.

Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>