Reference comparison is intentional. The END and DELIM string
constants are used as sentinels and will always be the same
instances.

Suppress both ReferenceEquality and StringEquality warnings.

Change-Id: I4ce0495702c56b3911f42f26c2f81d28073cbe19
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>

Deprecate the constant with the intention of making it private in
a future release.

All existing usage of the constant within JGit code has already been
replaced with the recommended alternatives in preceding commits.

Change-Id: I10eb95f3f92cb74f93a26bf1a6edd24615b75c6f
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>

Allows callers to read all lines in the input stream until the
END marker is reached, without having to explicitly check for
the END marker.

Replace all remaining usage of the END marker with the new method.

Change-Id: I51f419c7f569ab7ed01e1aaaf6b40ed8cdc2116b
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>

PacketLineIn.END is only referenced in tests. Replace most of those
with a new package visible end() method.

Remaining usages of PacketLineIn.END are in the form:

  while ((line = pckIn.readString()) != PacketLineIn.END) {

and are not trivial replacements, hence are not touched in this change.

Change-Id: Id77c5321ddcad127130b246bde8f08736e60e1ea
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>

Deprecate DELIM with the intention of making it private in a future
release.

Callers that want to test if a packet line string is the delimiter
should use the isDelimiter(String) method.

The only other references to DELIM in the JGit code are in tests. For
those, introduce a package visible delimiter() method.

Change-Id: I21e8bbac0ffb9ef710c9753e23435416b09a4891
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>

Change-Id: I279808b8ddd8a9230a35582c00867b811633dfe8
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>

These methods will allow clients to check for END and DELIM without
doing a reference comparison on the String objects, which raises
warnings from Error Prone.

Change-Id: I9e7e59843553ed4488ee8e864033198bbb60d67c
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>

Change-Id: I3b748620f067582afef20f144feebe40d0332be2
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>

Remove it from

 * package private functions.

 * try blocks

 * for loops

this was done with the following python script:

$ cat f.py
import sys
import re
import os

def replaceFinal(m):
  return m.group(1) + "(" +  m.group(2).replace('final ', '') + ")"

methodDecl = re.compile(r"^([\t ]*[a-zA-Z_ ]+)\(([^)]*)\)")

def subst(fn):
  input = open(fn)
  os.rename(fn, fn + "~")

  dest = open(fn, 'w')
  for l in input:
    l = methodDecl.sub(replaceFinal, l)
    dest.write(l)
  dest.close()


for root, dirs, files in os.walk(".", topdown=False):
  for f in files:
    if not f.endswith('.java'):
      continue

    full = os.path.join(root, f)
    print full
    subst(full)

Change-Id: If533a75a417594fc893e7c669d2c1f0f6caeb7ca
Signed-off-by: Han-Wen Nienhuys <hanwen@google.com>

Most pkt-lines (data-pkts) have the form

	pkt-len pkt-payload

where pkt-len is a string of 4 hexadecimal digits representing the
size in bytes of the pkt-line.  Since this size includes the size of
the pkt-len, no data-pkt has a length less than 4.

A pkt-line with a length field less than 4 can thus be used for
other purposes.  In Git protocol v1, the only such pkt-line was

	flush-pkt = "0000"

which was used to mark the end of a stream.  Protocol v2 (see
Documentation/technical/protocol-v2.txt in git.git) introduces a
second special pkt-line type:

	delim-pkt = "0001"

used to mark the end of a section within a stream, for example to
separate capabilities from the content of a command.

[jn: split out from a larger patch that made use of this support]

Change-Id: I10e7824fa24ed74c4f45624bd490bba978cf5c34
Signed-off-by: Jonathan Tan <jonathantanmy@google.com>
Signed-off-by: Jonathan Nieder <jrn@google.com>

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

Place a configurable upper bound on the amount of command data
received from clients during `git push`.  The limit is applied to the
encoded wire protocol format, not the JGit in-memory representation.
This allows clients to flexibly use the limit; shorter reference names
allow for more commands, longer reference names permit fewer commands
per batch.

Based on data gathered from many repositories at $DAY_JOB, the average
reference name is well under 200 bytes when encoded in UTF-8 (the wire
encoding).  The new 3 MiB default receive.maxCommandBytes allows about
11,155 references in a single `git push` invocation.  A Gerrit Code
Review system with six-digit change numbers could still encode 29,399
references in the 3 MiB maxCommandBytes limit.

Change-Id: I84317d396d25ab1b46820e43ae2b73943646032c
Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Imitate the packet tracing feature from C Git v1.7.5-rc0~58^2~1 (add
packet tracing debug code, 2011-02-24).  Unlike C Git, use the log4j
log level setting instead of the GIT_TRACE_PACKET environment variable
to enable tracing.

Tested as follows:

 1. Enable tracing by adding the lines

	log4j.logger.org.eclipse.jgit.transport=DEBUG, stderr
	log4j.additivity.org.eclipse.jgit.transport=false

    to org.eclipse.jgit.pgm/resources/log4j.properties.

 2. mvn package

 3. org.eclipse.jgit.pgm/target/jgit \
	ls-remote git://git.kernel.org/pub/scm/git/git 2>&1 |less

Then the output provides a trace of packets sent and received over
the wire:

  2016-08-24 16:36:42 DEBUG PacketLineOut:145 - git> git-upload-pack /pub/scm/git/git^@host=git.kernel.org^@
  2016-08-24 16:36:42 DEBUG PacketLineIn:165 - git< 2632c897f7 HEAD^@multi_ack thin-pack side-band side-band-64k ofs-delta shallow no-progress include-tag multi_ack_detailed symref=HEAD:refs/heads/master agent=git/2.8.4
  2016-08-24 16:36:42 DEBUG PacketLineIn:165 - git< e0c1ceafc5 refs/heads/maint

Change-Id: I5028c064f3ac090510386057cb4e6d30d4eae232
Signed-off-by: Dan Wang <dwwang@google.com>

If the client sent a well-formed enough request to see it wants to use
side-band-64k for status reporting (meaning its a modern client), but
any other command record was somehow invalid (e.g. corrupt SHA-1)
report the parsing exception using channel 3.  This allows clients to
see the failure and know the server will not be continuing.

git-core and JGit clients send all commands and then start a sideband
demux before sending the pack. By consuming all commands first we get
the client into a state where it can see and respond to the channel 3
server failure.

This behavior is useful on HTTPS connections when the client is buggy
and sent a corrupt command, but still managed to request side-band-64k
in the first line.

Change-Id: If385b91ceb9f024ccae2d1645caf15bc6b206130

A few classes such as Constanrs are marked with @SuppressWarnings, as are
toString() methods with many liternal, but otherwise $NLS-n$ is used for
string containing text that should not be translated. A few literals may
fall into the gray zone, but mostly I've tried to only tag the obvious
ones.

Change-Id: I22e50a77e2bf9e0b842a66bdf674e8fa1692f590

Change-Id: I763590a45d75f00a09097ab6f89581a3bbd3c797

PacketLineOut is already public. Make PacketLineIn partially public
in case an application needs to use some of the pkt-line protocol.

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

If the remote peer replies with "ERR %s" instead of "ACK %s common" or
"NAK" during ancestor negotiation in the fetch-pack/upload-pack
protocol, treat that as an exception that aborts processing with the
error text as supplied by the remote system.

This matches behavior with "ERR %s" during the advertisements, which
is also a way for the remote to abort processing.

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

Most "ACK %s continue", "ACK %s common", "NAK" strings that are read
by the readACK() method and readString() are shorter than the
lineBuffer already available.  Reuse that buffer when reading from
the network stream and converting to a string with RawParseUtils to
avoid unnecessary temporary byte array allocations.

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

This reverts commit 1e510ec20e.

Instead work around the warning by defining our constant by
constructing it through a StringBuilder.

Change-Id: If139509e769d649609c62eff359ebaea5dd286b2
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
CC: Matthias Sohn <matthias.sohn@sap.com>
CC: Chris Aniszczyk <caniszczyk@gmail.com>

The strings are externalized into the root resource bundles.
The resource bundles are stored under the new "resources" source
folder to get proper maven build.

Strings from tests are, in general, not externalized. Only in
cases where it was necessary to make the test pass the strings
were externalized. This was typically necessary in cases where
e.getMessage() was used in assert and the exception message was
slightly changed due to reuse of the externalized strings.

Change-Id: Ic0f29c80b9a54fcec8320d8539a3e112852a1f7b
Signed-off-by: Sasa Zivkov <sasa.zivkov@sap.com>

When reading pkt-lines off an InputStream we are quite likely to
consume a whole group of fairly short lines in rapid succession, such
as in the have exchange that occurs in the fetch-pack/upload-pack
protocol.  Rather than allocating a throwaway buffer for each
line's raw byte sequence, reuse a buffer that is equal to the small
side-band packet size, which is 1000 bytes.  Text based pkt-lines
are required to be less than this size because many widely deployed
versions of C Git use a statically allocated array of this length.

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

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>

The multi_ack_detailed extension breaks out the "ACK %s continue" status
code into "ACK %s common" and "ACK %s ready" states, making it easier to
discover which objects are truely common, and which objects are simply
on a chain the server doesn't care learning about.

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

According the javadoc, and implied by the name of the class, NB
is about network byte order. The purpose of moving the IO only,
and non-byte order related functions to another class is to
make it easier for new contributors to understand that they
can use these functions in general and it's also makes it easier
to understand where to put new IO related utility functions

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

Per CQ 3448 this is the initial contribution of the JGit project
to eclipse.org.  It is derived from the historical JGit repository
at commit 3a2dd9921c.

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