Documentation: explain push.default option a bit more

The previous documentation was explaining _what_ the options were doing,
but were of little help explaining _why_ a user should set his default to
either of the options.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Undocument deprecated alias 'push.default=tracking'

It's been deprecated since 53c4031 (Johan Herland, Wed Feb 16 2011,
push.default: Rename 'tracking' to 'upstream'), so it's OK to remove it
from documentation (even though it's still supported) to make the
explanations more readable.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t5528-push-default.sh: add helper functions

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
push: introduce new push.default mode "simple"

When calling "git push" without argument, we want to allow Git to do
something simple to explain and safe. push.default=matching is unsafe
when used to push to shared repositories, and hard to explain to
beginners in some contexts. It is debatable whether 'upstream' or
'current' is the safest or the easiest to explain, so introduce a new
mode called 'simple' that is the intersection of them: push to the
upstream branch, but only if it has the same name remotely. If not, give
an error that suggests the right command to push explicitely to
'upstream' or 'current'.

A question is whether to allow pushing when no upstream is configured. An
argument in favor of allowing the push is that it makes the new mode work
in more cases. On the other hand, refusing to push when no upstream is
configured encourages the user to set the upstream, which will be
beneficial on the next pull. Lacking better argument, we chose to deny
the push, because it will be easier to change in the future if someone
shows us wrong.

Original-patch-by: Jeff King <peff@peff.net>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t5570: use explicit push refspec

The default mode for push without arguments will change. Some warnings
are about to be enabled for such use, which causes some t5570 tests to
fail because they do not expect this output.

Fix this by passing an explicit refspec to git push. To that end, change
the calling conventions of test_remote_error in order to accomodate
extra command arguments.

Signed-off-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
push: document the future default change for push.default (matching -> simple)

It is too early to start warning loudly about the future default change
in favor of 'simple', since many users use different versions of Git, and
would be harmed if we advised them to explicitely set
'push.default=simple' when using old versions of Git.

Still, we want to document the upcomming change so that:

* Users who may be affected by the change get one more chance to know it
  in advance.

* We actually commit to changing the default, and avoid repeating past
  errors.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
push: start warning upcoming default change for push.default

In preparation for flipping the default to the "simple" mode from
the "matching" mode that is the historical default, start warning
users when they rely on unconfigured "git push" to default to the
"matching" mode.

Also, advertise for 'simple' where 'current' and 'upstream' are advised.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
push: suggested updates to push configuration documentation

Signed-off-by: Junio C Hamano <gitster@pobox.com>
fixup! t5528-push-default.sh: add helper functions

Signed-off-by: Junio C Hamano <gitster@pobox.com>
fixup! push: introduce new push.default mode "simple"

Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'tr/xdiff-fast-hash' into pu

Will merge to 'next'.

By Thomas Rast
* tr/xdiff-fast-hash:
  xdiff: load full words in the inner loop of xdl_hash_record
Merge branch 'nl/http-proxy-more' into pu

The code to talk to http proxies learn to use the same credential
API used to talk to the final http destinations.  This still needs
to peek into $ENV{HTTPS_PROXY}.

By Nelson Benitez Leon (5) and others
* nl/http-proxy-more:
  http: fix proxy password passing
  http: fix proxy authentication
  http: rename HTTP_REAUTH to HTTP_AUTH_RETRY
  http: Avoid limit of retrying request only twice
  http: handle proxy authentication failure (error 407)
  http: handle proxy proactive authentication
  http: try http_proxy env var when http.proxy config option is not set
Merge branch 'mm/push-default-switch-warning' into pu

This resurrects an ancient patch I wrote during a discussion we had in the
1.6.3-1.6.4 era.  This should probably come after ct/advise-push-default
topic and at that point the advise messages need to be rephrased, taking
the future default change into account.

By Matthieu Moy (6) and others
* mm/push-default-switch-warning:
  fixup! push: introduce new push.default mode "simple"
  fixup! t5528-push-default.sh: add helper functions
  push: suggested updates to push configuration documentation
  push: start warning upcoming default change for push.default
  push: document the future default change for push.default (matching -> simple)
  t5570: use explicit push refspec
  push: introduce new push.default mode "simple"
  t5528-push-default.sh: add helper functions
  Undocument deprecated alias 'push.default=tracking'
  Documentation: explain push.default option a bit more
Merge branch 'jc/split-blob' into pu

Not ready.

I finished the streaming checkout codepath, but as explained in
127b177 (bulk-checkin: support chunked-object encoding, 2011-11-30),
these are still early steps of a long and painful journey. At least
pack-objects and fsck need to learn the new encoding for the series
to be usable locally, and then index-pack/unpack-objects needs to
learn it to be used remotely.

Given that I heard a lot of noise that people want large files, and
that I was asked by somebody at GitTogether'11 privately for an
advice on how to pay developers (not me) to help adding necessary
support, I am somewhat dissapointed that the original patch series
that was sent almost two months ago still remains here without much
comments and updates from the developer community. I even made the
interface to the logic that decides where to split chunks easily
replaceable, and I deliberately made the logic in the original patch
extremely stupid to entice others, especially the "bup" fanboys, to
come up with a better logic, thinking that giving people an easy
target to shoot for, they may be encouraged to help out. The plan is
not working :-(.

* jc/split-blob:
  chunked-object: streaming checkout
  chunked-object: fallback checkout codepaths
  bulk-checkin: support chunked-object encoding
  bulk-checkin: allow the same data to be multiply hashed
  new representation types in the packstream
  packfile: use varint functions

Conflicts:
	t/t1050-large.sh
Merge branch 'jc/run-hook-env-1' into pu

Not urgent.

Updates run_hook() API to be much less specific to "commit".  It would
only be useful if people start doing more interesting things with hooks.

* jc/run-hook-env-1:
  run_hook(): enhance the interface to pass arbitrary environment
git-svn: use POSIX::sigprocmask to block signals

rev_map_set() tries to avoid being interrupted by signals.

The conventional way to achieve this is through sigprocmask(), which is
available in the standard POSIX module.

This is implemented by this patch.  One important consequence of it is
that the signal handlers won't be unconditionally set to SIG_DFL anymore
upon the first invocation of rev_map_set() as they used to.

[That said, I'm not convinced that messing with signals is necessary
(and sufficient) here at all, but my perl-foo is too weak for a more
intrusive change.]

Signed-off-by: Roman Kagan <rkagan@mail.ru>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-svn: ignore SIGPIPE

In HTTP with keep-alive it's not uncommon for the client to notice that
the server decided to stop maintaining the current connection only when
sending a new request.  This naturally results in -EPIPE and possibly
SIGPIPE.

The subversion library itself makes no provision for SIGPIPE.  Some
combinations of the underlying libraries do (typically SIG_IGN-ing it),
some don't.

Presumably for that reason all subversion commands set SIGPIPE to
SIG_IGN early in their main()-s.

So should we.

This, together with the previous patch, fixes the notorious "git-svn
died of signal 13" problem (see e.g.
http://thread.gmane.org/gmane.comp.version-control.git/134936).

Signed-off-by: Roman Kagan <rkagan@mail.ru>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-svn: drop redundant blocking of SIGPIPE

Now that SIGPIPE is ignored there's no point blocking it.

Signed-off-by: Roman Kagan <rkagan@mail.ru>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Makefile: feed all header files to xgettext

Translation markers may be present in header files too. Make sure we
don't miss any.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
strbuf: convenience format functions with \n automatically appended

These functions are helpful when we do not want to expose \n to
translators. For example

    printf("hello world\n");

can be converted to

    printf_ln(_("hello world"));

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>