This ports the following options from rev-list based git-log
implementation:

 * -<n>, -n<n>, and -n <n>.  I am still wondering if we want
    this natively supported by setup_revisions(), which already
    takes --max-count.  We may want to move them in the next
    round.  Also I am not sure if we can get away with not
    setting revs->limited when we set max-count.  The latest
    rev-list.c and revision.c in this series do not, so I left
    them as they are.

 * --pretty and --pretty=<fmt>.

 * --abbrev=<n> and --no-abbrev.

The previous commit already handles time-based limiters
(--since, --until and friends).  The remaining things that
rev-list based git-log happens to do are not useful in a pure
log-viewing purposes, and not ported:

 * --bisect (obviously).

 * --header.  I am actually in favor of doing the NUL
   terminated record format, but rev-list based one always
   passed --pretty, which defeated this option.  Maybe next
   round.

 * --parents.  I do not think of a reason a log viewer wants
   this.  The flag is primarily for feeding squashed history
   via pipe to downstream tools.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

Well, assuming breaking --merge-order is fine, here's a patch (on top of
the other ones) that makes

	git log <filename>

actually work, as far as I can tell.

I didn't add the logic for --before/--after flags, but that should be
pretty trivial, and is independent of this anyway.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This actually moves the "meat" of the revision walking from rev-list.c
to the new library code in revision.h. It introduces the new functions

	void prepare_revision_walk(struct rev_info *revs);
	struct commit *get_revision(struct rev_info *revs);

to prepare and then walk the revisions that we have.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This makes the rewrite easier to validate in that revision flag
parsing and warlking part are now all in rev_info structure.
Signed-off-by: NJunio C Hamano <junkio@cox.net>

This really just splits things up partially, and creates the
interface to set things up by parsing the command line.

No real code changes so far, although the parsing of filenames is a bit
stricter. In particular, if there is a "--", then we do not accept any
filenames before it, and if there isn't any "--", then we check that _all_
paths listed are valid, not just the first one.

The new argument parsing automatically also gives us "--default" and
"--not" handling as in git-rev-parse.
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
Signed-off-by: NJunio C Hamano <junkio@cox.net>

The old revision.h helper header isn't used any more, but I never noticed
it until I started grepping for ULONG_MAX users.

This allows fsck to verify not just that an object exists, but
also that it has the type it was expected to have.

Also, make it a fatal error to pass in a non-commit object. The callers
never checked, so better check here.

This simplifies merge-base further. It's now so trivial that it's almost
ridiculous.

 - mark_reachable() can be more generic, marking the reachable revisions
   with an arbitrary mask.
 - date parsing will parse to a date of 0 rather than ULONG_MAX for the
   bad old case, sorting the dates correctly.

This also drops the old-style date parsing. We just don't care
enough, since we dropped that format pretty early.

Yes, this could do with some cleanup, and a common library file.
Some day.

It's really a very generic thing: the notion of one sha1 revision
referring to another one. "fsck" uses it for all nodes, and "rev-tree"
only tracks commit-node relationships, but the code was already
the same - now we just make that explicit by moving it to a common
header file.