remote.c: add command line option parser for "--lockref"

Update "git push" and "git send-pack" to parse this commnd line
option.

The intended sematics is:

 * "--lockref" alone, without specifying the details, will protect
   _all_ remote refs that are going to be updated by requiring their
   current value to be the same as the remote-tracking branch we
   have for them, unless otherwise specified;

 * "--lockref=refname", without specifying the expected value, will
   protect that refname, if it is going to be updated, by requiring
   its current value to be the same as the remote-tracking branch we
   have for it;

 * "--lockref=refname:value" will protect that refname, if it is
   going to be updated, by requiring its current value to be the
   same as the specified value (which is allowed to be different
   from the remote-tracking branch we have for the refname, or we do
   not even have to have such a remote-tracking branch when this
   form is used); and

 * "--no-lockref" will cancel all the previous --lockref on the
   command line.

In any of the forms, when we try to use a remote-tracking branch for
the remote ref being updated, it is an error if there is no such
remote-tracking branch on our end.

Because the command line options are parsed _before_ we know which
remote we are pushing to, there needs further processing to the
parsed data after we instantiate the transport object to:

 * expand "refname" given by the user to a full refname to be
   matched with the list of "struct ref" used in match_push_refs()
   and set_ref_status_for_push(); and

 * learning the actual local ref that is the remote-tracking branch
   for the specified remote ref.

Further, some processing need to be deferred until we find the set
of remote refs and match_push_refs() returns in order to find the
ones that need to be checked after explicit ones have been processed
for "--lockref" (no specific details).

These post-processing will be the topic of the next patch.

Oh, of course, the option name is still not cast in stone.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---

 This round makes --lockref simply a weaker form of --force.

 The old version used to allow "--lockref=<refname>:" to say "I want
 this push to create <refname>, any existing old value should make
 it fail", but the normal fast-forward check already implements it,
 so there is no need for such an option.  This round removes it.

 The old version allowed you to express "I want the old value of
 'master' to be at X and also I want the update to fast-forward" by
 giving only "--lockref=master:X" without "--force".  Because you
 already know if the commit you are updating their 'master' with
 fast-forwards from X or not, such a combination is unnecessary to
 support.  This simplifies the UI greatly, as "--force" can again be
 the big red button that overrides all the safety.

 I think the option now should be renamed to "--force-with-???"; you
 are essentially taking a lease on the ref before you start your
 rebase, and making sure the ref hasn't been updated by other
 people, you are safely forcing your push of a rebased history.

 Perhaps "--force-with-lease"?  "--force-leased-ref"?
push --lockref: implement logic to populate old_sha1_expect[]

This plugs the push_cas_option data collected by the command line
option parser to the transport system with a new function
apply_push_cas(), which is called after match_push_refs() has
already been called.

At this point, we know which remote we are talking to, and what
remote refs we are going to update, so we can fill in the details
that may have been missing from the command line, such as

 (1) what abbreviated refname the user gave us matches the actual
     refname at the remote; and

 (2) which remote tracking branch in our local repository to read the
     value of the object to expect at the remote.

to populate the old_sha1_expect[] field of each of the remote ref.

Still nobody uses this information, which is the topic of the next
patch.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
push --lockref: tie it all together

This teaches the deepest part of the callchain for "git push" (and
"git send-pack") to enforce "the old value of the ref must be this,
otherwise fail this push" (aka "compare-and-swap" / "--lockref").

Signed-off-by: Junio C Hamano <gitster@pobox.com>
t5533: test "push --lockref"

Prepare two repositories, src and dst, the latter of which is a
clone of the former (with tracking branches), and push from the
latter into the former, using --lockref=name (using tracking ref for
"name" when updating "name"), --lockref=name:value, --lockref=name:
(i.e. check creation), and --lockref (using tracking ref for
anything that we update).

Signed-off-by: Junio C Hamano <gitster@pobox.com>
request-pull: improve error message for invalid revision args

Currently, when an invalid revision is specified, the error message is:

    fatal: Needed a single revision

This is misleading because, you might think there is something wrong
with the command line as a whole.

Now the user gets a more meaningful error message, showing the invalid
revision.

Signed-off-by: Dirk Wallenstein <halsmit@t-online.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t3032 - make compatible with systems using \r\n as a line ending

Subtests 6, 7, and 9 rely test that merge-recursive correctly
ignores whitespace when so directed. These tests create and test for
lines ending in \r\n, but as this is a valid line separator on Windows,
convert such lines in the output to avoid confusion by line-oriented
grep.

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t6131 - skip tests if on case-insensitive file system

This test fails on Cygwin where the default system configuration does not
support case sensitivity (only case retention), so don't run the test on
such systems.

Signed-off-by: Mark Levedahl <mlevedahl@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
daemon/shell: refactor redirection of 0/1/2 from /dev/null

Both daemon.c and shell.c contain logic to open FDs 0/1/2 from
/dev/null if they are not already open.  Move the function in daemon.c
to setup.c and use it in shell.c, too.

While there, remove a 'not' that inverted the meaning of the comment.
The point is indeed to *avoid* messing up.

Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git: ensure 0/1/2 are open in main()

Not having an open FD in the 0--2 range can lead to strange results,
for example, a subsequent open() may return 2 (stderr) and then a
die() would clobber this file.

git-daemon and git-shell already guarded against this, but apparently
users also manage to trip over it in other git commands.  So we call
sanitize_stdfds() during main git startup.

Since these FDs are inherited, this covers all use of 'git foo ...',
and all internal C commands when called directly.  It does not fix
shell/perl commands called directly.

Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-log.txt: fix typesetting of example "git-log -L" invocation

All surrounding examples are typeset as monospaced text. Follow suit.

Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Acked-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
apply, entry: speak of submodules instead of subprojects

There are only four (with some generous rounding) instances in the
current source code where we speak of "subproject" instead of
"submodule".  They are as follows:

* one error message in git-apply and two in entry.c

* the patch format for submodule changes

The latter was introduced in 0478675 (Expose subprojects as special
files to "git diff" machinery, 2007-04-15), apparently before the
terminology was settled.  We can of course not change the patch
format.

Let's at least change the error messages to consistently call them
"submodule".

Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t4000-diff-format.sh: modernize style

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff: allow --no-patch as synonym for -s

This follows the usual convention of having a --no-foo option to negate
--foo.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff: allow --patch & cie to override -s/--no-patch

All options that trigger a patch output now override --no-patch.

The case of --binary deserves extra attention: the name may suggest that
it turns a normal patch into a binary patch, but it actually already
enables patch output when normally disabled (e.g. "git log --binary"
displays a patch), hence it makes sense for "git show --no-patch
--binary" to display the binary patch.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/git-show.txt: include common diff options, like git-log.txt

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation: move description of -s, --no-patch to diff-options.txt

Technically, "-s, --no-patch" is implemented in diff.c ("git diff
--no-patch" is essentially useless, but valid). From the user point of
view, this allows the documentation to show up in "git show --help",
which is one of the most useful use of the option.

While we're there, add a sentence explaining why the option can be
useful.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/git-log.txt: capitalize section names

This is the convention in most other files and even at the beginning of
git-log.txt

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
show-ref: make --head always show the HEAD ref

The docs seem to say that doing

	git show-ref --head --tags

would show both the HEAD ref and all the tag refs. However, doing
both --head and either of --tags or --heads would filter out the HEAD
ref.

Also update the documentation to describe the new behavior and add
tests for the show-ref command.

[jc: Doug did proofread the tests, but it was done by me and bugs in
it are mine].

Signed-off-by: Doug Bell <madcityzen@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
.mailmap: René Scharfe has a new email address

Signed-off-by: RenÃ© Scharfe <l.s.r@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
line-range: fix "blame -L X,-N" regression

"blame -L X,-N" is documented as blaming "N lines ending at X".  In
practice, the behavior is achieved by swapping the two range endpoints
if the second is less than the first.  25ed3412 (Refactor parse_loc;
2013-03-28) broke this interpretation by removing the swapping code from
blame.c and failing to add it to line-range.c along with other code
relocated from blame.c. Thus, such a range is effectively treated as
empty.  Fix this regression.

Signed-off-by: Eric Sunshine <sunshine@sunshineco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>