http auth fails with multiple curl handles

Create a repo with multiple loose objects in order to demonstrate http
authentication breakage.

Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fix http auth with multiple curl handles

HTTP authentication is currently handled by get_refs and fetch_ref, but
not by fetch_object, fetch_pack or fetch_alternates. In the
single-threaded case, this is not an issue, since get_refs is always
called first. It recognigzes the 401 and prompts the user for
credentials, which will then be used subsequently.

If the curl multi interface is used, however, only the multi handle used
by get_refs will have credentials configured. Requests made by other
handles fail with an authentication error.

Fix this by setting CURLOPT_USERPWD whenever a slot is requested.

Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
http: clean up leak in init_curl_http_auth

When we have a credential to give to curl, we must copy it
into a "user:pass" buffer and then hand the buffer to curl.
Old versions of curl did not copy the buffer, and we were
expected to keep it valid. Newer versions of curl will copy
the buffer.

Our solution was to use a strbuf and detach it, giving
ownership of the resulting buffer to curl. However, this
meant that we were leaking the buffer on newer versions of
curl, since curl was just copying it and throwing away the
string we passed. Furthermore, when we replaced a
credential (e.g., because our original one was rejected), we
were also leaking on both old and new versions of curl.

This got even worse in the last patch, which started
replacing the credential (and thus leaking) on every http
request.

Instead, let's use a static buffer to make the ownership
more clear and less leaky.  We already keep a static "struct
credential", so we are only handling a single credential at
a time, anyway.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
http: use newer curl options for setting credentials

We give the username and password to curl by sticking them
in a buffer of the form "user:pass" and handing the result
to CURLOPT_USERPWD. Since curl 7.19.1, there is a split
mechanism, where you can specify each element individually.

This has the advantage that a username can contain a ":"
character. It also is less code for us, since we can hand
our strings over to curl directly. And since curl 7.17.0 and
higher promise to copy the strings for us, we we don't even
have to worry about memory ownership issues.

Unfortunately, we have to keep the ugly code for old curl
around, but as it is now nicely #if'd out, we can easily get
rid of it when we decide that 7.19.1 is "old enough".

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
stash: use eval_gettextln correctly

Otherwise, passing an invalid option, git stash -v, gave:

git-stash: line 204: $'error: unknown option for \'stash save\':
$option\n       To provide a message, use git stash save -- \'$option\'':
command not found

Signed-off-by: Ross Lagerwall <rosslagerwall@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
properly keep track of current working directory

Various failure modes in the repository detection code path currently
quote the wrong directory in their error message. The working directory
is changed iteratively to the parent directory until a git repository is
found. If the working directory cannot be changed to the parent
directory for some reason, the detection gives up and prints an error
message. The error message should report the current working directory.

Instead of continually updating the 'cwd' variable, which is actually
used to remember the original working directory, the 'offset' variable
is used to keep track of the current working directory. At the point
where the affected error handling code is called, 'offset' already
points to the end of the parent of the working directory, rather than
the current working directory.

Fix this by explicitly using a variable 'offset_parent' and update
'offset' concurrently with the call to chdir.

In a similar fashion, the function get_device_or_die() would print the
original working directory in case of a failure, rather than the current
working directory. Fix this as well by making use of the 'offset'
variable.

Lastly, replace the phrase 'mount parent' with 'mount point'. The former
appears to be a typo.

Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
cherry-pick: do not expect file arguments

If a commit-ish passed to cherry-pick or revert happens to have a file
of the same name, git complains that the argument is ambiguous and
advises to use '--'. To make things worse, the '--' argument is removed
by parse_options, und so passing '--' has no effect.

Instead, always interpret cherry-pick/revert arguments as revisions.

Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff: avoid stack-buffer-read-overrun for very long name

Due to the use of strncpy without explicit NUL termination,
we could end up passing names n1 or n2 that are not NUL-terminated
to queue_diff, which requires NUL-terminated strings.
Ensure that each is NUL terminated.

Signed-off-by: Jim Meyering <meyering@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fetch: Give remote_ref to update_local_ref() as well

This way, the function can look at the remote side to adjust the
informational message it gives.

Signed-off-by: Marc Branchaud <marcnarc@xiplink.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
fetch: describe new refs based on where it came from

update_local_ref() used to say "[new branch]" when we stored a new ref
outside refs/tags/ hierarchy, but the message is more about what we
fetched, so use the refname at the origin to make that decision.

Also, only call a new ref a "branch" if it's under refs/heads/.

Signed-off-by: Marc Branchaud <marcnarc@xiplink.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge tests: octopus with redundant parents

This happens when git merge is run to merge multiple commits that are
descendants of current HEAD (or are HEAD).  We've hit this while updating
master to origin/master but accidentaly we called (while being on master):

	$ git merge master origin/master

Here is a minimal testcase:

	$ git init a && cd a
	$ echo a >a && git add a
	$ git commit -minitial
	$ echo b >a && git add a
	$ git commit -msecond
	$ git checkout master^

	$ git merge master master
	Fast-forwarding to: master
	Already up-to-date with master
	Merge made by the 'octopus' strategy.
	 a |    2 +-
	  1 files changed, 1 insertions(+), 1 deletions(-)

	$ git cat-file commit HEAD
	tree eebfed94e75e7760540d1485c740902590a00332
	parent bd679e85202280b263e20a57639a142fa14c2c64
	author Michał Kiedrowicz <michal.kiedrowicz@gmail.com> 1329132996 +0100
	committer Michał Kiedrowicz <michal.kiedrowicz@gmail.com> 1329132996 +0100

	Merge branches 'master' and 'master' into HEAD

Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/merge.c: remove "remoteheads" global variable

Instead pass it around starting from the toplevel cmd_merge()
as an explicit parameter.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/merge.c: collect other parents early

Move the code around to populate remoteheads list early in the process
before any decision regarding twohead vs octopus and fast-forwardness is
made.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/merge.c: reduce parents early

Instead of waiting until we record the parents of resulting merge, reduce
redundant parents (including our HEAD) immediately after reading them.

The change to t7602 illustrates the essence of the effect of this change.
The octopus merge strategy used to be fed with redundant commits only to
discard them as "up-to-date", but we no longer feed such redundant commits
to it and the affected test degenerates to a regular two-head merge.

And obviously the known-to-be-broken test in t6028 is now fixed.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
fmt-merge-msg: discard needless merge parents

This is used by "git pull" to construct a merge message from list of
remote refs.  When pulling redundant set of refs, however, it did not
filter them even though the merge itself discards them as unnecessary.

Teach the command to do the same for consistency.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
sequencer: remove additional blank line

Remove an additional blank line between the
headline and the list of conflicted files after
doing a recursive merge.

Signed-off-by: Ralf Thielow <ralf.thielow@googlemail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-remote-testgit: fix race when spawning fast-import

Test "pushing to local repo" in t5800-remote-helpers can hang
due to a race condition in git-remote-testgit.  Fix it by
setting stdin to unbuffered.

On the writer side, "git push" invokes push_refs_with_export(),
which sends to stdout the command "export\n" and immediately
starts up "git fast-export".  The latter writes its output stream
to the same stdout.

On the reader side, remote helper "git-remote-testgit" reads from
stdin to get its next command.  It uses getc() to read characters
from libc up until \n.  Libc has buffered a potentially much
larger chunk of stdin.  When it sees the "export\n" command, it
forks "git fast-import" to read the stream.

If fast-export finishes before git fast-import starts, the
fast-export output can end up in libc's buffer in
git-remote-testgit, rather than in git fast-import.  The latter
hangs indefinitely on a now-empty stdin.

Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
config: reject bogus section names for --rename-section

You can feed junk to "git config --rename-section", which
will result in a config file that git will not even parse
(so you cannot fix it with git-config). We already have
syntactic sanity checks when setting a variable; let's do
the same for section names.

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff --no-index: use strbuf for temporary pathnames

Instead of using limited-length buffers and risking of pathname
truncation, we should be taking advantage of strbuf API nowadays.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
t5570: fix forwarding of git-daemon messages via cat

The shell function that starts git-daemon wants to read the first line of
the daemon's stderr to ensure that it started correctly. Subsequent daemon
errors should be redirected to fd 4 (which is the terminal in verbose mode
or /dev/null in quiet mode). To that end the shell script used 'read' to
get the first line of output, and then 'cat &' to forward everything else
in a background process.

The problem is, that 'cat >&4 &' does not produce any output because the
shell redirects a background process's stdin to /dev/null. To have this
command invocation do anything useful, we have to redirect its stdin
explicitly (which overrides the /dev/null redirection).

The shell function connects the daemon's stderr to its consumers via a
FIFO. We cannot just do this:

   read line <git_daemon_output
   cat <git_daemon_output >&4 &

because after the first redirection the pipe is closed and the daemon
could receive SIGPIPE if it writes at the wrong moment. Therefore, we open
the readable end of the FIFO only once on fd 7 in the shell and dup from
there to the stdin of the two consumers.

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>