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>

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

Checking in the change from wish to wish8.4 was a mistake; I had
changed it for a test but forgot to change it back before checking
in a patch.

This is a careful version of the script stuff that currently just
blindly writes HEAD with a new value.

You can use

	git-update-ref HEAD <newhead>

or

	git-update-ref HEAD <newhead> <oldhead>

where the latter version verifies that the old value of HEAD matches
oldhead.

It basically allows a "ref" file to be a symbolic pointer to another ref
file by starting with the four-byte header sequence of "ref:".

More importantly, it allows the update of a ref file to follow these
symbolic pointers, whether they are symlinks or these "regular file
symbolic refs".

NOTE! It follows _real_ symlinks only if they start with "refs/":
otherwise it will just try to read them and update them as a regular file
(ie it will allow the filesystem to follow them, but will overwrite such a
symlink to somewhere else with a regular filename).

In general, using

	git-update-ref HEAD "$head"

should be a _lot_ safer than doing

	echo "$head" > "$GIT_DIR/HEAD"

both from a symlink following standpoint _and_ an error checking
standpoint.  The "refs/" rule for symlinks means that symlinks that point
to "outside" the tree are safe: they'll be followed for reading but not
for writing (so we'll never write through a ref symlink to some other
tree, if you have copied a whole archive by creating a symlink tree).
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The merge strategies can give more descriptive error messages for
conflict cases if they are given the actual branch names instead of
the SHA1s.
Signed-off-by: NFredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

If the working tree is dirty read-tree will fail, and we don't want an
ugly stack trace in that case. Also make sure we don't print stack
traces when we use 'die'.
Signed-off-by: NFredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The new output format shows only the status letter and paths.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

When many paths are modified, rename detection takes a lot of time.
The new option -l<num> can be used to disable rename detection when
more than <num> paths are possibly created as renames.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This is a long overdue clean-up to the code for parsing and passing
diff options.  It also tightens some constness issues.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Now we conditionally compile things in compat/, so we should remove
object files there.  Python execution can leave *.pyc and *.pyo, which
need to be cleaned as well.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Also cmd-renames.sh can now be used to remove the backward compatible
symlinks -- this is not used by default in any way.

As discussed on the list with Pasky, git-ssh-push and git-ssh-pull will
keep calling each other for a while longer.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

It was ignoring the generation number of the commit when naming 2nd
and later parents, showing "(linus^n)^2" for any <n> incorrectly as
"linus^2".
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Fix missing symbol explanations, a few incorrect cases, and add
two-way merge rules.
Signed-off-by: NDaniel Barkalow <barkalow@iabervon.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>