Typically we refer to the raw InputStream (the stream without the
pkt-line headers on it) as rawIn, and the pkt-line header variant
as pckIn.  Refactor our fields to reflect that.  To ensure these
are actually the same underlying InputStream, we now create our own
PacketLineIn wrapper around the supplied raw InputStream.  Its a
very low-cost object since it has only the 4 byte length buffer.

Instead of hardcoding the header length as 5, use the constant from
SideBandOutputStream.  This makes it a bit more clear what we are
consuming, exactly here.

Change-Id: Iebd05538042913536b88c3ddc3adc3a86a841cc5
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Instead of relying on our callers to wrap us up inside of a
BufferedOutputStream and using the proper block sizing, do the
buffering directly inside of SideBandOutputStream.  This ensures
we don't get large write-throughs from BufferedOutputStream that
might overflow the configured packet size.

The constructor of SideBandOutputStream is also beefed up to check
its arguments and ensure they are within acceptable ranges for the
current side-band protocol.

Change-Id: Ic14567327d03c9e972f9734b8228178bc448867d
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

If the readAdvertisedRefs() method throws an exception, its already
closed the connection and wrapped the underlying cause inside of a
suitable TransportException object that it is throwing.  We shouldn't
catch IOException and rethrow a wrapped copy here, because we'll double
wrap the exception thrown by readAdvertisedRefs.  This may obsecure the
root cause of the connection failure from the end-user.

Change-Id: I0ca61560f9888c666323dac8a5582aab25e897ff
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

When a user of ReceivePack or UploadPack wants to control what refs
are sent to the client, for instance when some refs should be hidden
from some clients, this interface can be extended to provide a fine
grained control over what refs are sent to the client.

Change-Id: Ie6320b0f8922e1a5e1bad91c016bd476ea094366

The boolean field sentCommand is always true at this point, as it
was assigned just 5 lines above.  So we always set the status of
the update command object to AWAITING_REPORT.

Simplify the logic by dropping the ?: operator.  I assume this is
older code from an attempt to manage dry-run push support within
the native connection, but in fact dry-run support is done higher
up inside of PushProcess.

Change-Id: I450d491bbbb5afecdbf5444ab7169222e856a3bb
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

JGit relies on JUnit 3, not JUnit 4.

Change-Id: Ic5a0ae1564d7744c203321857fc603e7008dbf13
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Change-Id: I17e2c22498092d25dace88319698626ce55df822

Somehow we missed setting this up for the project.

Change-Id: Id55a6415f5fd03a7cd9d4d4ecbdd726cef79430d
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Change-Id: Ie4133083a1cb1730f3dba52c0b8d359c7ed845e6
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Windows users by default have core.autocrlf set to true. JGit
does not recognize the flags and thus works as if it is set. In order
to make JGit more compatible with msysgit we set the flag to false
in repositories that JGit creates.

Bug: 301775
Change-Id: I7ea462fe3516e5060b87aa1f7ed63689936830c2
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>

Doing a keep call with a length of 1 will copy the current entry just
like the previous add was doing, but it avoids doing any validation
on the entry.  This is sane because the entry can be assumed to be
already valid, since its originating from the destination index.

Change-Id: I250d902fc98580444af1ba4b8fedceb654541451
Originally: http://thread.gmane.org/gmane.comp.version-control.git/128214/focus=128213


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

A 0 file mode in a DirCacheEntry is not a valid mode.  To C git
such a value indicates the record should not be present.  We already
were catching this bad state and exceptioning out when writing tree
objects to disk, but we did not fail when writing the dircache back
to disk.  This allowed JGit applications to create a dircache file
which C git would not like to read.

Instead of checking the mode during writes, we now check during
mutation.  This allows application bugs to be detected sooner and
closer to the cause site.  It also allows us to avoid checking most
of the records which we read in from disk, as we can assume these
are formatted correctly.

Some of our unit tests were not setting the FileMode on their test
entry, so they had to be updated to use REGULAR_FILE.

Change-Id: Ie412053c390b737c0ece57b8e063e4355ee32437
Originally: http://thread.gmane.org/gmane.comp.version-control.git/128214/focus=128213


Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
CC: Adam W. Hawks <awhawks@writeme.com>

A dircache record must not use a path string like "/a" or "a//b"
as this results in a tree entry being written with a zero length
name component in the record.  C git does not support an empty name,
and neither does any modern filesystem.

A record also must not have a stage outside of the standard 0-3
value range, as there are only 2 bits of space available in the
on-disk format of the record to store the stage information.
Any other values would be truncated into this space, storing a
different value than the caller expected.

If an application tries to create a DirCache record with either of
these wrong values, we abort with an IllegalArgumentException.

Change-Id: I699de149efdfccd85d8adde07d3efd080e3b49c2
Originally: http://thread.gmane.org/gmane.comp.version-control.git/128214


Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
CC: Adam W. Hawks <awhawks@writeme.com>

Rather than implementing the file reading logic ourselves, and
wind up leaking the FileInputStream's file descriptor until the
next GC, use IO.readFully(File) which wraps the read loop inside
of a try/finally to ensure the stream is closed before it exits.

Change-Id: I85a3fe87d5eff88fa788962004aebe19d2e91bb4
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Reviewed-by: Roland Grunberg <rgrunber@redhat.com>

Actually set the range of versions we are willing to accept for
each package we import, lest we import something in the future
that isn't compatible with our needs.

Change-Id: I25dbbb9eaabe852631b677e0c608792b3ed97532
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

ObjectWalk is invoking next() for each record we consider in a tree.
Rather than doing several method calls against the current parser,
and testing if we are at eof() at least twice per next() invocation,
do it only once and inline the logic to move the parser forward.

Change-Id: If5938f5d7b3ca24f500a184c9bd2ef193015414e
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

The supplied test case comes out of the example tree identified by
Robert de Wilde and Ilari on #git:

  $ git ls-tree -rt a54f1a85ebf6a7f53aa60a45a1be33f8b078fb7e
  040000 tree bfe058ad536cdb12e127cde63b01472c960ea105    A
  040000 tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904    A/A
  040000 tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904    A/B
  100644 blob abbbfafe3129f85747aba7bfac992af77134c607    B

In this tree, "B" was being skipped because "A/A" as an empty tree
was immediately followed by "A/B", also an empty tree, but the
ObjectWalk broke out too early and never visited "B".

Bug: 286653
Change-Id: I25bcb0bc99d0cbbbdd9c2bd625ad6a691a6d0335
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

During dispose() or reset() we are suppose to be restoring the
ObjectWalk instance back to the original pre-walk state, but we
failed to reset the tree parser.  This can lead to confusing state
if the ObjectWalk was reused by the caller, as entries from the
old walk might be reported as part of the new walk.

Change-Id: I6237bae7bfd3794e8b9a92b4dd475559cc72e634
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Instead of including "ObjectId[SHA-1]" in the message, just
us the formatted SHA-1 name of the object by calling name().

Change-Id: I0d1d0e8207f8a3f02188e60242e4e9bf7420e88f
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

We didn't skip the correct number of bytes when we skipped over an
unrecognized but optional dircache extension.  We missed skipping
the 8 byte header that makes up the extension's name and length.

We also didn't include the skipped extension's payload as part of
our index checksum, resuting in a checksum failure when the index
was done reading.  So ensure we always scan through a skipped
section and include it in the checksum computation.

Add a test case for a currently unsupported index extension, 'ZZZZ',
to verify we can still read the DirCache object even though we
don't know what 'ZZZZ' is supposed to mean.

Bug: 301287
Change-Id: I4bdde94576fffe826d0782483fd98cab1ea628fa
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

This test doesn't actually depend upon the large data set we have
in the RepositoryTestCase, so drop that from the dependency and
use the more simple LocalDiskRepositoryTestCase instead.

Change-Id: I0fd4affe1dd5ec86e8c3253db42df11d3b612e36
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

When running jgit from inside Eclipse (e.g. rightclick on project
org.eclipse.jgit.pgm and select Run as->Java application) no commands
are found. This is because the commands are loaded from a resource file
/META-INF/services/org.eclipse.jgit.pgm.TextBuiltin and this file is
not anymore on the classpath.
I fixed this by modifying .classpath to contain the META-INF directory.

Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>

If the repository is empty, we have no HEAD branch, which means we
can't test to see if the HEAD is detached and should be advertised
as a .have line.

Change-Id: I6e85f836e7db057cede812d0d6c1aecbd6cbe6c5
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

The new plugin contains the bulk of the logic to scan a Git repository,
and query IPZilla, in order to produce an XML formatted IP log for the
requested revision of any Git based project.  This plugin is suitable
for embedding into a servlet container, or into the Eclipse workbench.

The command line pgm package knows how to invoke this plugin through
the eclipse-iplog subcommand, permitting storage of the resulting
log as a local XML file.

Change-Id: If01d9d98d07096db6980292bd5f91618c55d00be
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

The unsetSection method can be used to delete an entire configuration
block, such as a [branch ""] or [remote ""] section in a file.

Change-Id: I93390c9b2187eb1b0d51353518feaed83bed2aad
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>

Change-Id: I55b42bca435c538a8c5534c68813568a2188b55b
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Ensure the background Jetty threads have been able to write the
request log record before the JUnit thread tries to read the set
of requests back.  This wait is necessary because the JUnit thread
may be able to continue as soon as Jetty has finished writing
the response onto the socket, and hasn't necessarily finished the
post-response logging activity.

By using a semaphore with a fixed number of resources, and using
one resource per request, but all of them when we want to read the
log, we implement a simple lock that requires there be no active
requests when we want to get the log from the JUnit thread.

Change-Id: I499e1c96418557185d0e19ba8befe892f26ce7e4
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Config was confusing the following two variables when writing the
file back to text format:

  [my]
    empty =
    enabled

When parsed, we say that my.empty has 1 value, null, and my.enabled
is an empty string value that in boolean context should be evaluated
as true.

Saving this configuration file back to text format was ignoring the
null value for my.empty, producing a completely different file than
what Config read:

  [my]
    empty
    enabled

Instead handle the writing differently to ensure the original format
is output.  New tests cases cover the expected behavior and return
values from accessor methods.

Change-Id: Id37379ce20cb27e3330923cf989444dd9f2bdd96
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

We don't want to use the JRE cache when fetching content.

Change-Id: Id76f3e618967c98ed4fbc47a1a2a9e77acbe41ab
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

If remote.name.uploadpack or .receivepack is misconfigured and points
to a non-existent command on the remote system, we should receive back
exit status 127.  Report this case specially with the command we used
so the user knows what is going.

Bug: 293703
Change-Id: I7504e7b6238d5d8e698d37db7411c4817a039d08
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>

Annotated tags created with C Git versions before the introduction
of c818566 ([PATCH] Update tags to record who made them, 2005-07-14),
do not have a "tagger" line present in the object header.  This line
did not appear in C Git until v0.99.1~9.

Ancient projects such as the Linux kernel contain such tags, for
example Linux 2.6.12 is older than when this feature first appeared
in C Git.  Linux v2.6.13-rc4 in late July 2005 is the first kernel
version tag to actually contain a tagger line.

It is therefore acceptable for the header to be missing, and for
the RevTag.getTaggerIdent() method to return null.

Since the Javadoc for getTaggerIdent() already explained that the
identity may be null, we just need to test that this is true when
the header is missing, and allow the ObjectChecker to pass anyway.

Change-Id: I34ba82e0624a0d1a7edcf62ffba72260af6f7e5d
See: http://code.google.com/p/gerrit/issues/detail?id=399


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