Don't translate the patch to UTF-8, instead preserve the data as
is.  This also reverts a test case that was included in the
original patch series.

Also allow overwriting the authorship and title information we
gather from RFC2822 mail headers with additional in-body
headers, which was pointed out by Linus.
Signed-off-by: NDon Zickus <dzickus@redhat.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Fix the bug that caused "blobdiff" view called with new style URI
for a rename with change diff to be show as new (added) file diff.

New style URI for "blobdiff" for rename means with $hash_base ('hb') and
$hash_parent_base ('hpb') paramaters denoting tree-ish (usually commit)
of a blobs being compared, together with both $file_name ('f') and
$file_parent ('fp') parameters.

It is done by adding $file_parent ('fp') to the path limiter, meaning
that diff command becomes:

	git diff-tree [options] hpb hb -- fp f

Other option would be finding hash of a blob using git_get_hash_by_path
subroutine and comparing blobs using git-diff, or using extended SHA-1
syntax and compare blobs using git-diff:

	git diff [options] hpb:fp hp:f
Signed-off-by: NJakub Narebski <jnareb@gmail.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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

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

* maint:
  git-upload-pack: make sure we close unused pipe ends
  Documentation/git-rev-parse.txt: fix example in SPECIFYING RANGES.
  Documentation/git-svnimport.txt: fix typo.

Bryan Wu reported
/usr/local/bin/git-quiltimport: 114: Syntax error: Missing '))'

Most bourne-ish shells I have here accept
 x=$((echo x)|cat)
but all bourne-ish shells I have here accept
 x=$( (echo x)|cat)
because $(( might mean arithmetic expansion.
Signed-off-by: NFrancis Daly <francis@daoine.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

So we can remove the specific message in "bisect_run".
Signed-off-by: NChristian Couder <chriscool@tuxfamily.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

* 'master' of git://repo.or.cz/git/mergetool.git:
  mergetool: Clean up description of files and prompts for merge resolutions
  mergetool: Make git-rm quiet when resolving a deleted file conflict
  mergetool: Add support for Apple Mac OS X's opendiff command
  mergetool: Fix abort command when resolving symlinks and deleted files
  mergetool: Remove spurious error message if merge.tool config option not set
  mergetool: factor out common code
  mergetool: portability fix: don't use reserved word function
  mergetool: portability fix: don't assume true is in /bin
  mergetool: Don't error out in the merge case where the local file is deleted
  mergetool: Replace use of "echo -n" with printf(1) to be more portable
  Fix minor formatting issue in man page for git-mergetool

This fixes complaints from Junio for how messages and prompts are
printed when resolving symlink and deleted file merges.
Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>

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

Signed-off-by: NArjen Laarhoven <arjen@yaph.org>
Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>

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

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

Create common function check_unchanged(), save_backup() and
remove_backup().

Also fix some minor whitespace issues while we're at it.
Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>

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

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

If the file we are trying to merge resolve is in git-ls-files -u, then
skip the file existence test.  If the file isn't reported in
git-ls-files, then check to see if the file exists or not to give an
appropriate error message.
Signed-off-by: N"Theodore Ts'o" <tytso@mit.edu>

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

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

Right now, we don't close the read end of the pipe when git-upload-pack
runs git-pack-object, so we hang forever (why don't we get SIGALRM?)
instead of dying with SIGPIPE if the latter dies, which seems to be the
norm if the client disconnects.

Thanks to Johannes Schindelin <Johannes.Schindelin@gmx.de> for
pointing out where this close() needed to go.

This patch has been tested on kernel.org for several weeks and appear
to resolve the problem of git-upload-pack processes hanging around
forever.
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>
(cherry picked from commit 465b3518)

Please see http://bugs.debian.org/404795:

 In git-rev-parse(1), there is an example commit tree, which is used twice.
 The explanation for this tree is very clear: B and C are commit *parents* to
 A.

 However, when the tree is reused as an example in the SPECIFYING RANGES, the
 manpage author screws up and uses A as a commit *parent* to B and C!  I.e.,
 he inverts the tree.

 And the fact that for this example you need to read the tree backwards is
 not explained anywhere (and it would be confusing even if it was).
Signed-off-by: NGerrit Pape <pape@smarden.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This was noticed by Frederik Schwarzer.  SVN's repository by default has
trunk, tags/, and branch_es_/.
Signed-off-by: NGerrit Pape <pape@smarden.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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

The function replace_encoding_header is given the whole
commit buffer, including the commit message. When looking
for the encoding header, if none was found in the header, it
would locate any line in the commit message matching
"\nencoding " and remove it.

Instead, we now make sure to search only to the end of the
header.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Elias Pipping:
> I'm on a mac, hence /usr/bin/sed is not gnu sed, which makes
> t4118 fail.
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Ack'd-by: Elias Pipping <pipping@macports.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Especially this tests i18n messages and encoding header.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

It printed the header "encoding " instead of just showing
the encoding, as all other items do.
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

There are two breakages in the %P/%p interpolation.  It appended
an excess SP at the end of the list, and it gave uninitialized
contents of a buffer on the stack for root commits.

This fixes it, while updating the t6006 test which expected the
wrong output.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NGerrit Pape <pape@smarden.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Please see http://bugs.debian.org/409887

http-fetch expected the URL given at the command line to have a trailing
slash anyway, and then added '/objects...' when requesting objects files
from the http server.

Now it doesn't require the trailing slash in <url> anymore, and strips
trailing slashes if given nonetheless.
Signed-off-by: NGerrit Pape <pape@smarden.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

It still looks at the working tree and checks for locally
modified paths.  When are preparing a temporary index from HEAD,
we do not want any of that.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

These could stand to be a little more complex, but it should
at least catch obvious problems (like the recently fixed %ct
bug).
Signed-off-by: NJeff King <peff@peff.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Right now, we don't close the read end of the pipe when git-upload-pack
runs git-pack-object, so we hang forever (why don't we get SIGALRM?)
instead of dying with SIGPIPE if the latter dies, which seems to be the
norm if the client disconnects.

Thanks to Johannes Schindelin <Johannes.Schindelin@gmx.de> for
pointing out where this close() needed to go.

This patch has been tested on kernel.org for several weeks and appear
to resolve the problem of git-upload-pack processes hanging around
forever.
Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

A pointer arithmetic error in fill_person caused random data
from the commit object to be included with the timestamp,
which looked something like:

    $ git-rev-list --pretty=format:%ct origin/next | head
    commit 98453bdb3db10db26099749bc4f2dc029bed9aa9
    1174977948 -0700

    Merge branch 'master' into next

    * master:
      Bisect: Use
    commit c0ce981f
    1174889646 -0700
Signed-off-by: NJeff King <peff@peff.net>
Acked-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJames Bowes <jbowes@dangerouslyinc.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJames Bowes <jbowes@dangerouslyinc.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

At least in Linux glibc, "getaddrinfo()" has a very irritating feature (or
bug, who knows..).

Namely if you pass it in an empty string for the service name, it will
happily and quietly consider it identical to a NULL port pointer, and
return port number zero and no errors. Which obviously will not work.

Maybe that's what it's really expected to do, although the man-page for
getaddrinfo() certainly implies that it's a bug.

So when somebody passes me a "please pull" request pointing to something
like the following

	git://git.kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git

(note the extraneous colon at the end of the host name), git would happily
try to connect to port 0, which would generally just cause the remote to
not even answer, and the "connect()" will take a long time to time out.

So to work around the glibc feature/bug, just notice this empty port case
automatically. Also, add the port information to the error information
when it fails to look up (maybe it's the host-name that fails, maybe it's
the port-name - we should print out both).
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>