Alexey Nezhdanov updated CVSps to generate author-name and
author-email information in its output.

If the input looks like it has that already properly formatted,
use that without our own munging.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

archimport was refusing to import commits that had merges from repositories
that it didn't know about. Fixed.

Also brings in nicer messages.
Signed-off-by: NMartin Langhoff <martin@catalyst.net.nz>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The archive generated with git-tar-tree had 0755 and 0644 mode bits.
This inconvenienced the extractor with umask 002 by robbing g+w bit
unconditionally.  Just write it out with loose permissions bits and
let the umask of the extractor do its job.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Fix the last two holdouts that forced mode bits stricter than the user's umask.
Noticed by Wolfgang Denk and fixed by Linus.

[jc: applied the same fix to mailsplit just for the sake of consistency.]
Signed-off-by: NJunio C Hamano <junkio@cox.net>

A patch that contains no actual diff, and that doesn't change any
meta-data is bad. It shouldn't be a patch at all, and git-apply shouldn't
just accept it.

This caused a corrupted patch to be silently applied as an empty change in
the kernel, because the corruption ended up making the patch look empty.

An example of such a patch is one that contains the patch header, but
where the initial fragment header (the "@@ -nr,.." line) is missing,
causing us to not parse any fragments.

The real "patch" program will also flag such patches as bad, with the
message

	patch: **** Only garbage was found in the patch input.

and we should do likewise.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NJunio C Hamano <junio@twinsun.com>

After seeing Jeff's guide, I changed my mind about the
big-rename transition plan.  Even if Porcelains are kept up to
date, those web documents that describes older world order would
live longer and people will stumble across them via google
searches.  And who knows how many mirrored copies there are.

The backward compatible symbolic links *will* be removed before
1.0.  But that will not happen in 0.99.8.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The core part detected and died upon seeing a corrupted packfile, but
did not help the user by telling which packfile is corrupt and how.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Make logerror() and loginfo() static

logerror() and loginfo() in daemon.c are never declared and never called
from other files, therefore they should be declared static.  Found by
sparse.
Signed-off-by: NPavel Roskin <proski@gnu.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

... so try to set it only in later versions.
Signed-off-by: NJohannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This again makes git-pull to use git-merge, so that different merge
strategy can be specified from the command line.  Without explicit
strategy parameter, it defaults to git-merge-resolve if only one
remote is pulled, and git-merge-octopus otherwise, to keep the
default behaviour of the command the same as the original.

Also this brings another usability measure: -n flag from the command
line, if given, is passed to git-merge to prevent it from running the
diffstat at the end of the merge.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This uses the git-update-ref command in scripts for safer updates.
Also places where we used to read HEAD ref by using "cat" were fixed
to use git-rev-parse.  This will matter when we start using symbolic
references.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Insert 'static' where appropriate.
Signed-off-by: NPeter Hagervall <hager@cs.umu.se>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Added support for additional CURL SSL settings via environment variables.
Client certificate/key files can be specified as well as alternate CA
information.
Signed-off-by: NNick Hengeveld <nickh@reactrix.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NTom Prince <tom.prince@ualberta.net>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The merge strategy would check this itself and typically does it
by using git-read-tree -m -u 3-way merge.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The refspecs specified in the .git/remotes/<remote> on the "Pull: "
lines are for fetching multiple heads in one go, but most of the time
making an Octopus out of them is not what is wanted.  Make git-fetch
leave the marker in .git/FETCH_HEAD file so that later stages can
tell which heads are for merging and which are not.

Tom Prince made me realize how stupid the original behaviour was.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

It still talked about "the proposed alternative semantics" but we have
used those alternative semantics for quite some time.  Update them to
avoid confusion.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Now update-index supports '-z --stdin', we do not have to rely on
platform xargs to support -0 option.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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

The new option --stdin reads list of paths to be updated from the
standard input.  As usual, -z means the paths are terminated with NUL
characters, as opposed to LF without that option.

This is useful to use git-diff-files -z and git-ls-files -z when the
platform xargs does not support -0 option, and obviously saves one
process even when xargs can take -0.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Return CURL error message when object transfer fails

[jc: added similar curl_errorstr errors to places where we
 use curl_easy_perform() to run fetch that _must_ succeed.]
Signed-off-by: NNick Hengeveld <nickh@reactrix.com>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

With the --recover option, we verify that we have absolutely
everything reachable from the target, not assuming that things
reachable from refs will be complete.
Signed-off-by: NDaniel Barkalow <barkalow@iabervon.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Signed-off-by: NSven Verdoolaege <skimo@kotnet.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This is from Peter Eriksen, but further fixed.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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

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

Only the "Fetching ... using http" was leaking to stdout.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

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

My stupidity deserved to be yelled at by Linus ... there is no reason
to require the working tree to be clean when merging -- the only
requirements are index to match HEAD commit and the paths involved in
merge are up to date in the working tree.  Revert and cherry-pick are
just specialized forms of merge, and the requirements should be the
same.

Remove the 'general purpose routine to make sure tree is clean' from
git-sh-setup, to prevent me from getting tempted again.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Being able to try multiple strategies and automatically picking one
that seems to give less conflicting result may or may not much sense
in practice.  At least that should not force normal use case to
additionally require the working tree to be fully clean.  As Linus
shouted, local changes do not matter unless they interfere with the
merge.

This commit changes git-merge not to require a clean working tree.
Only when we will iterate through more than one merge strategies,
local changes are stashed away before trying the first merge, and
restored before second and later merges are attempted.

The index file must be in sync with HEAD in any case -- otherwise the
merge result would contain changes since HEAD that was done locally
and registered in the index.  This check is already enforced by
three-way read-tree existing merge strategies use, but is done here as
a safeguard as well.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

And with -n flag you can tell it not to.
Signed-off-by: NJunio C Hamano <junkio@cox.net>