When accepting revision SHA1 IDs from the frontend verify the SHA1
actually refers to a blob and is known to exist.  Its an error
to use a SHA1 in a tree if the blob doesn't exist as this would
cause git-fsck-objects to report a missing blob should the pack get
closed without the blob being appended into it or a subsequent pack.
So right now we'll just ask that the frontend "pre-declare" any
blobs it wants to use in a tree before it can use them.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

The tree of the current commit can be altered by file_change commands
before the commit gets written to the pack.  The file changes are
rather primitive as they simply allow removal of a tree entry or
setting/adding a tree entry.

Currently trees and commits aren't being deltafied when written to
the pack and branch reloading from the current pack doesn't work,
so at most 5 branches can be worked with at any one time.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

This provides the basic data structures needed to store trees in
memory while we are processing them for a branch.  What we are
attempting to do is track one complete tree for each branch that
the frontend has registered with us through the 'newb' (new_branch)
command.  When the frontend edits that tree through 'updf' or 'delf'
commands we'll mark the affected tree(s) as being dirty and recompute
their objects during 'comt' (commit).

Currently the protocol is decidedly _not_ user friendly.  I crashed
fast-import by giving it bad input data from Perl.  I may try to
improve upon it, or at least upon its error handling.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Moved the new_blob logic off into a new subroutine and
invoked it when getting the 'blob' command.

Added statistics dump to STDERR when the program terminates listing
what it did at a high level.  This is somewhat interesting.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Too many globals variables were being used not not enough
code was resuable to process trees and commits so this is
a simple refactoring of the existing blob processing code
to get into a state that will be easier to handle trees
and commits in.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Although its easy to ask the user to tell us how many objects they
will need, its probably better to dynamically grow the object table
in large units.  But if the user can give us a hint as to roughly
how many objects then we can still use it during startup.

Also stopped printing the SHA1 strings to stdout as no user is
currently making use of that facility.
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Signed-off-by: NShawn O. Pearce <spearce@spearce.org>

Signed-off-by: NShawn O. Pearce <spearce@spearce.org>