The patch format shows complete rewrite as deletion of all old lines
followed by addition of all new lines.  Count lines consistenly with
that when doing diffstat.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

* jc/diff:
  Libified diff-index: backward compatibility fix.
  Libify diff-index.
  Libify diff-files.

Foolishly I renamed diff.o around which caused an old diff.o
taken out of libgit.a and got linked into resulting binary and
exhibited mysterious breakage for many people.  This borrows
from the kernel Makefile (scripts/Makefile.build) to first remove
the target and then recreate.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

* fix:
  Document the configuration file
  Document git-var -l listing also configuration variables
  rev-parse: better error message for ambiguous arguments

This patch adds a Documentation/config.txt file included by git-repo-config
and currently aggregating hopefully all the available git plumbing / core
porcelain configuration variables, as well as briefly describing the format.

It also updates an outdated bit of the example in git-repo-config(1).
Signed-off-by: NPetr Baudis <pasky@suse.cz>

Signed-off-by: NPetr Baudis <pasky@suse.cz>

Currently, if git-rev-parse encounters an argument that is neither a
recognizable revision name nor the name of an existing file or
directory, and it hasn't encountered a "--" argument, it prints an
error message saying "No such file or directory".  This can be
confusing for users, including users of programs such as gitk that
use git-rev-parse, who may then think that they can't ask about the
history of files that no longer exist.

This makes it print a better error message, one that points out the
ambiguity and tells the user what to do to fix it.
Signed-off-by: NPaul Mackerras <paulus@samba.org>

* ar/chmod-series:
  make update-index --chmod work with multiple files and --stdin

* sh/daemon:
  socksetup: don't return on set_reuse_addr() error

* jc/cc-stat:
  Fix "git show --stat"

* jc/unresolve:
  git-update-index --unresolve
  Add git-unresolve <paths>...

* jc/color:
  Add colordiff for git to contrib/colordiff.

* git://git.kernel.org/pub/scm/gitk/gitk:
  gitk: Let git-rev-list do the argument list parsing

This is a fix for a problem reported by Jim Radford where an argument
list somewhere overflows on repositories with lots of tags.  In fact
it's now unnecessary to use git-rev-parse since git-rev-list can take
all the arguments that git-rev-parse can.  This is inspired by but not
the same as the solutions suggested by Jim Radford and Linus Torvalds.
Signed-off-by: NPaul Mackerras <paulus@samba.org>

The patch makes "--chmod=-x" and "--chmod=+x" act like "--add"
and "--remove" to affect the behaviour of the command for the
rest of the path parameters, not just the following one.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

"diff-index -m" does not mean "do not ignore merges", but means
"pretend missing files match the index".

The previous round tried to address this, but failed because
setup_revisions() ate "-m" flag before the caller had a chance
to intervene.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The second installment to libify diff brothers.  The pathname
arguments are checked more strictly than before because we now
use the revision.c::setup_revisions() infrastructure.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This is the first installment to libify diff brothers.

The updated diff-files uses revision.c::setup_revisions()
infrastructure to parse its command line arguments, which means
the pathname arguments are checked more strictly than before.
The tests are adjusted to separate possibly missing paths from
the rest of arguments with double-dashes, to show the kosher
way.

As Linus pointed out, renaming diff.c to diff-lib.c was simply
stupid, so I am renaming it back.  The new diff-lib.c is to
contain pieces extracted from diff brothers.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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

I hacked it up to teach it the git extended diff headers, made
it not to read the whole patch in the array.

Also, the original program, when arguments are given, ran "diff"
with the given arguments and showed the output from it.  Of
course, I changed it to run "git diff" ;-).
Signed-off-by: NJunio C Hamano <junkio@cox.net>

* jc/diff:
  diff --stat: do not drop rename information.

builtin-help.c wants to include common-cmds.h which is a
generated file.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Right now it split it into "builtin-log.c" for log-related commands
("log", "show" and "whatchanged"), and "builtin-help.c" for the
informational commands (usage printing and "help" and "version").

This just makes things easier to read, I find.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

* fix:
  git-log produces no output

When $PAGER is set to 'less -i', we used to fail because we
assumed the $PAGER is a command and simply exec'ed it.

Try exec first, and then run it through shell if it fails.  This
allows even funkier PAGERs like these ;-):

	PAGER='sed -e "s/^/`date`: /" | more'
	PAGER='contrib/colordiff.perl | less -RS'
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

* fix:
  fix pack-object buffer size
  mailinfo: decode underscore used in "Q" encoding properly.
  Reintroduce svn pools to solve the memory leak.
  pack-objects: do not stop at object that is "too small"

The input line has 40 _chars_ of sha1 and no 20 _bytes_. It should also
account for the space before the pathname, and the terminating \n and \0.
Signed-off-by: NNicolas Pitre <nico@cam.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Quoted-Printable (RFC 2045) and the "Q" encoding (RFC 2047) are
subtly different; the latter is used on the mail header and an
underscore needs to be decoded to 0x20.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Introduced in 4802426d.
Signed-off-by: NSanti Béjar <sbejar@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Because we sort the delta window by name-hash and then size,
hitting an object that is too small to consider as a delta base
for the current object does not mean we do not have better
candidate in the window beyond it.

Noticed by Shawn Pearce, analyzed by Nico, Linus and me.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

* fix:
  git-commit --amend: two fixes.

When running "git commit --amend" only to fix the commit log
message without any content change, we mistakenly showed the
git-status output that says "nothing to commit" without
commenting it out.

If you have already run update-index but you want to amend the
top commit, "git commit --amend --only" without any paths should
have worked, because --only means "starting from the base
commit, update-index these paths only to prepare the index to
commit, and perform the commit".  However, we refused -o without
paths.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Retire git-unresolve and make it into "git-update-index --unresolve".
It processes all paths that follow.

During a merge, you would mark a path that is dealt with with:

	$ git update-index hello

and you would "undo" it with:

	$ git update-index --unresolve hello
Signed-off-by: NJunio C Hamano <junkio@cox.net>

When a verbatim rename or copy is detected, we did not show
anything on the "diff --stat" for the filepair.  This makes it
to show the rename information.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This is an attempt to address the issue raised on #git channel
recently by Carl Worth.

After a conflicted automerge, "git diff" shows a combined diff
to give you how the tentative automerge result differs from
what came from each branch.  During a complex merge, it is
tempting to be able to resolve a few paths at a time, mark
them "I've dealt with them" with git-update-index to unclutter
the next "git diff" output, and keep going.  However, when the
final result does not compile or otherwise found to be a
mismerge, the workflow to fix the mismerged paths suddenly
changes to "git diff HEAD -- path" (to get a diff from our
HEAD before merging) and "git diff MERGE_HEAD -- path" (to get
a diff from theirs), and it cannot show the combined anymore.

With git-unresolve <paths>..., the versions from our branch and
their branch for specified blobs are placed in stage #2 and
stage #3, without touching the working tree files.  This gives
you the combined diff back for easier review, along with
"diff --ours" and "diff --theirs".

One thing it does not do is to place the base in stage #1; this
means "diff --base" would behave differently between the run
immediately after a conflicted three-way merge, and the run
after an update-index by mistake followed by a git-unresolve.

We could theoretically run merge-base between HEAD and
MERGE_HEAD to find which tree to place in stage #1, but
reviewing "diff --base" is not that useful so....
Signed-off-by: NJunio C Hamano <junkio@cox.net>

* lt/xsha1:
  get_tree_entry(): make it available from tree-walk
  sha1_name.c: no need to include diff.h; tree-walk.h will do.
  sha1_name.c: prepare to make get_tree_entry() reusable from others.
  get_sha1() shorthands for blob/tree objects

* maint:
  pre-commit hook: complain about conflict markers.
  git-merge: a bit more readable user guidance.

Now I am not doing any real "git-diff in C" yet, but this would
help before doing so.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Several <<< or === or >>> characters at the beginning of a line
is very likely to be leftover conflict markers from a failed
automerge the user resolved incorrectly, so detect them.

As usual, this can be defeated with "git commit --no-verify" if
you really do want to have those files, just like changes that
introduce trailing whitespaces.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

We said "fix up by hand" after failed automerge, which was a big
"Huh?  Now what?".  Be a bit more explicit without being too
verbose. Suggested by Carl Worth.
Signed-off-by: NJunio C Hamano <junkio@cox.net>