trailer: ignore comment lines inside the trailers

Otherwise trailers that are commented out might be
processed. We would also error out if the comment line
char is also a separator.

This means that comments inside a trailer block will
disappear, but that was already the case anyway.

Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
trailer: display a trailer without its trailing newline

Trailers passed to the parse_trailer() function often have
a trailing newline. When erroring out, we should display
the invalid trailer properly, that means without any
trailing newline.

Helped-by: Junio C Hamano <gitster@pobox.com>
Helped-by: Jeff King <peff@peff.net>
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
doc: add some crossrefs between manual pages

In particular, git-fast-import and -export link to each
other, and gitremote-helpers links to existing remote
helpers, and vice versa. Also link to fast-import from the
remote helper spec, as this is relevant for remote helpers
using the fast-import format.

Signed-off-by: Max Horn <max@quendi.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
SubmittingPatches: final submission is To: maintainer and CC: list

In an earlier part there is:

  "re-send it with "To:" set to the maintainer [*1*] and "cc:" the list [*2*]"

for the final submission, but later we see

  "Send it to the list and cc the maintainer."

Fix the later one to match the previous.

Signed-off-by: Slavomir Vlcek <svlc@inventati.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t5705: the file:// URL should be absolute

The test misused a URL "file://." to mean "relative to here",
which we no longer accept.

In a file:// URL, typically there is no host, and RFC1738 says that
file:///<path> should be used.

Update t5705 to use a working URL.

Reported-by: Michael Blume <blume.mike@gmail.com>
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gittutorial: fix output of 'git status'

'git status' doesn't output leading '#'s these days.

Signed-off-by: Stefan Naewe <stefan.naewe@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'cc/interpret-trailers'

Small fixes to a new experimental command already in 'master'.

* cc/interpret-trailers:
  trailer: display a trailer without its trailing newline
  trailer: ignore comment lines inside the trailers
Merge branch 'tb/no-relative-file-url'

* tb/no-relative-file-url:
  t5705: the file:// URL should be absolute
Merge branch 'mh/doc-remote-helper-xref'

* mh/doc-remote-helper-xref:
  doc: add some crossrefs between manual pages
Merge branch 'sn/tutorial-status-output-example'

* sn/tutorial-status-output-example:
  gittutorial: fix output of 'git status'
Merge branch 'sv/submitting-final-patch'

* sv/submitting-final-patch:
  SubmittingPatches: final submission is To: maintainer and CC: list
pass TIME_DATE_NOW to approxidate future-check

The approxidate functions accept an extra "now" parameter to
avoid calling time() themselves. We use this in our test
suite to make sure we have a consistent time for computing
relative dates. However, deep in the bowels of approxidate,
we also call time() to check whether possible dates are far
in the future. Let's make sure that the "now" override makes
it to that spot, too, so we can consistently test that
feature.
approxidate: allow ISO-like dates far in the future

When we are parsing approxidate strings and we find three
numbers separate by one of ":/-.", we guess that it may be a
date. We feed the numbers to match_multi_number, which
checks whether it makes sense as a date in various orderings
(e.g., dd/mm/yy or mm/dd/yy, etc).

One of the checks we do is to see whether it is a date more
than 10 days in the future. This was added in 38035cf (date
parsing: be friendlier to our European friends.,
2006-04-05), and lets us guess that if it is currently April
2014, then "10/03/2014" is probably March 10th, not October
3rd.

This has a downside, though; if you want to be overly
generous with your "--until" date specification, we may
wrongly parse "2014-12-01" as "2014-01-12" (because the
latter is an in-the-past date). If the year is a future year
(i.e., both are future dates), it gets even weirder. Due to
the vagaries of approxidate, months _after_ the current date
(no matter the year) get flipped, but ones before do not.

This patch drops the "in the future" check for dates of this
form, letting us treat them always as yyyy-mm-dd, even if
they are in the future. This does not affect the normal
dd/mm/yyyy versus mm/dd/yyyy lookup, because this code path
only kicks in when the first number is greater than 70
(i.e., it must be a year, and cannot be either a date or a
month).

The one possible casualty is that "yyyy-dd-mm" is less
likely to be chosen over "yyyy-mm-dd". That's probably OK,
though because:

  1. The difference happens only when the date is in the
     future. Already we prefer yyyy-mm-dd for dates in the
     past.

  2. It's unclear whether anybody even uses yyyy-dd-mm
     regularly. It does not appear in lists of common date
     formats in Wikipedia[1,2].

  3. Even if (2) is wrong, it is better to prefer ISO-like
     dates, as that is consistent with what we use elsewhere
     in git.

[1] http://en.wikipedia.org/wiki/Date_and_time_representation_by_country
[2] http://en.wikipedia.org/wiki/Calendar_date