split_ident: parse timestamp from end of line

Split_ident currently parses left to right. Given this
input:

  Your Name <email@example.com> 123456789 -0500\n

We assume the name starts the line and runs until the first
"<".  That starts the email address, which runs until the
first ">".  Everything after that is assumed to be the
timestamp.

This works fine in the normal case, but is easily broken by
corrupted ident lines that contain an extra ">". Some
examples seen in the wild are:

  1. Name <email>-<> 123456789 -0500\n

  2. Name <email> <Name<email>> 123456789 -0500\n

  3. Name1 <email1>, Name2 <email2> 123456789 -0500\n

Currently each of these produces some email address (which
is not necessarily the one the user intended) and end up
with a NULL date (which is generally interpreted as the
epoch by "git log" and friends).

But in each case we could get the correct timestamp simply
by parsing from the right-hand side, looking backwards for
the final ">", and then reading the timestamp from there.

In general, it's a losing battle to try to automatically
guess what the user meant with their broken crud. But this
particular workaround is probably worth doing.  One, it's
dirt simple, and can't impact non-broken cases. Two, it
doesn't catch a single breakage we've seen, but rather a
large class of errors (i.e., any breakage inside the email
angle brackets may affect the email, but won't spill over
into the timestamp parsing). And three, the timestamp is
arguably more valuable to get right, because it can affect
correctness (e.g., in --until cutoffs).

This patch implements the right-to-left scheme described
above. We adjust the tests in t4212, which generate a commit
with such a broken ident, and now gets the timestamp right.
We also add a test that fsck continues to detect the
breakage.

For reference, here are pointers to the breakages seen (as
numbered above):

[1] http://article.gmane.org/gmane.comp.version-control.git/221441

[2] http://article.gmane.org/gmane.comp.version-control.git/222362

[3] http://perl5.git.perl.org/perl.git/commit/13b79730adea97e660de84bbe67f9d7cbe344302

Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
bash prompt: don't use '+=' operator in show upstream code path

The '+=' operator is not supported by old Bash versions (3.0) we still
care about.

Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
revision: do not peel tags used in range notation

A range notation "A..B" means exactly the same thing as what "^A B"
means, i.e. the set of commits that are reachable from B but not
from A.  But the internal representation after the revision parser
parsed these two notations are subtly different.

 - "rev-list ^A B" leaves A and B in the revs->pending.objects[]
   array, with the former marked as UNINTERESTING and the revision
   traversal machinery propagates the mark to underlying commit
   objects A^0 and B^0.

 - "rev-list A..B" peels tags and leaves A^0 (marked as
   UNINTERESTING) and B^0 in revs->pending.objects[] array before
   the traversal machinery kicks in.

This difference usually does not matter, but starts to matter when
the --objects option is used.  For example, we see this:

    $ git rev-list --objects v1.8.4^1..v1.8.4 | grep $(git rev-parse v1.8.4)
    $ git rev-list --objects v1.8.4 ^v1.8.4^1 | grep $(git rev-parse v1.8.4)
    04f013dc38d7512eadb915eba22efc414f18b869 v1.8.4

With the former invocation, the revision traversal machinery never
hears about the tag v1.8.4 (it only sees the result of peeling it,
i.e. the commit v1.8.4^0), and the tag itself does not appear in the
output.  The latter does send the tag object itself to the output.

Make the range notation keep the unpeeled objects and feed them to
the traversal machinery to fix this inconsistency.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
graph: fix coloring around octopus merges

When drawing the graph of an octopus merge, we draw a horizontal line
from parents 3 and above into the asterisk representing the commit. The
sections of this line should be colored to match the graph lines coming
in from above.

However, if the commit is not in the left-most column we do not take
into account the columns to the left of the commit when calculating
these colors. Fix this by adding the appropriate offset to the column
index used for calculating the color.

Signed-off-by: Hemmo Nieminen <hemmo.nieminen@iki.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
checkout: allow dwim for branch creation for "git checkout $branch --"

The "--" notation disambiguates files and branches, but as a side-effect
of the previous implementation, also disabled the branch auto-creation
when $branch does not exist.

A possible scenario is then:

git checkout $branch
=> fails if $branch is both a ref and a file, and suggests --

git checkout $branch --
=> refuses to create the $branch

This patch allows the second form to create $branch, and since the -- is
provided, it does not look for file named $branch.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
checkout: proper error message on 'git checkout foo bar --'

The previous code was detecting the presence of "--" by looking only at
argument 1. As a result, "git checkout foo bar --" was interpreted as an
ambiguous file/revision list, and errored out with:

error: pathspec 'foo' did not match any file(s) known to git.
error: pathspec 'bar' did not match any file(s) known to git.
error: pathspec '--' did not match any file(s) known to git.

This patch fixes it by walking through the argument list to find the
"--", and now complains about the number of references given.

Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
doc/howto: warn about (dumb)http server document being too old

Describe when it is still applicable, and tell people where to go
for most normal cases.

Signed-off-by: Sitaram Chamarty <sitaram@atc.tcs.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
subtree: add makefile target for html docs

The Makefile currently builds the roff manpage, but not the
html form. As some people may prefer the latter, let's make
it an option to build that, too. We also wire it into "make
doc" so that it is built by default.

This patch does not build or install it as part of
"install-doc"; that would require extra infrastructure to
handle installing the html as we do in git's regular
Documentation/ tree. That can come later if somebody is
interested.

Tested-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation: restore a space in unpack-objects usage

The commit 87b7b84 removed a space in the unpack-objects usage, which
makes the synopsis a bit confusing. This patch simply restores it.

Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation: "pack-file" is not literal in unpack-objects

Make it clear that "pack-file" is not to be spelled as is in the
unpack-objects usage.

Signed-off-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitignore.txt: fix documentation of "**" patterns

"**" means bold in ASCIIDOC, so we need to escape it.

Signed-off-by: Karsten Blees <blees@dcon.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'jc/revision-range-unpeel' into maint

"git rev-list --objects ^v1.0^ v1.0" gave v1.0 tag itself in the
output, but "git rev-list --objects v1.0^..v1.0" did not.

* jc/revision-range-unpeel:
  revision: do not peel tags used in range notation
Merge branch 'jk/split-broken-ident' into maint

The fall-back parsing of commit objects with broken author or
committer lines were less robust than ideal in picking up the
timestamps.

* jk/split-broken-ident:
  split_ident: parse timestamp from end of line
Merge branch 'sg/prompt-svn-remote-fix' into maint

Bash prompting code to deal with an SVN remote as an upstream
were coded in a way not supported by older Bash versions (3.x).

* sg/prompt-svn-remote-fix:
  bash prompt: don't use '+=' operator in show upstream code path
Merge branch 'mm/checkout-auto-track-fix' into maint

"git checkout topic", when there is not yet a local "topic" branch
but there is a unique remote-tracking branch for a remote "topic"
branch, pretended as if "git checkout -t -b topic remote/$r/topic"
(for that unique remote $r) was run. This hack however was not
implemented for "git checkout topic --".

* mm/checkout-auto-track-fix:
  checkout: proper error message on 'git checkout foo bar --'
  checkout: allow dwim for branch creation for "git checkout $branch --"
Merge branch 'hn/log-graph-color-octopus' into maint

Coloring around octopus merges in "log --graph" output was screwy.

* hn/log-graph-color-octopus:
  graph: fix coloring around octopus merges
Merge branch 'jk/subtree-install-fix' into maint

We did not generate HTML version of documentation to "git subtree"
in contrib/.

* jk/subtree-install-fix:
  subtree: add makefile target for html docs
Merge branch 'vd/doc-unpack-objects' into maint

The synopsis section of "git unpack-objects" documentation has been
clarified a bit.

* vd/doc-unpack-objects:
  Documentation: "pack-file" is not literal in unpack-objects
  Documentation: restore a space in unpack-objects usage
Merge branch 'sc/doc-howto-dumb-http' into maint

An ancient How-To on serving Git repositories on an HTTP server
lacked a warning that it has been mostly superseded with more
modern way.

* sc/doc-howto-dumb-http:
  doc/howto: warn about (dumb)http server document being too old
Start preparing for 1.8.4.3

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