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

JGits PushCommand and BasePackPushConnection were throwing a generic
exception when the pushed pack-file was rejected by the server since it
contained too large objects. Teach JGit to better analyze the server's
response to detect this situation and throw a more specific exception.

Detect this situation by parsing the status line sent by the server.
This change only recognizes the response sent by a JGit based server.
All other servers which report such problems in a different way still
lead to a generic TransportExceptions.

Also see https://git.eclipse.org/r/#/c/46348/

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

This should mirror the behavior of `git push --atomic` where the
client asks the server to apply all-or-nothing. Some JGit servers
already support this based on a custom DFS backend. InMemoryRepository
is extended to support atomic push for unit testing purposes.

Local disk server side support inside of JGit is a more complex animal
due to the excessive amount of file locking required to protect every
reference as a loose reference.

Change-Id: I15083fbe48447678e034afeffb4639572a32f50c

These commands' monitor fields can never be null unless someone passes
null to setProgressMonitor.  Anyone passing null probably meant to
disable the ProgressMonitor, so do that (by falling back to
NullProgressMonitor.INSTANCE) instead of saving a null and eventually
producing NullPointerException.

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

JGits PushCommand and BasePackPushConnection were throwing generic
TransportExceptions when the pushed pack-file was rejected by the server
since it was too big. Let JGit better interprete the server's response
to detect this situation and throw a more specific exception.

This detection works by parsing the status line sent by the server. This
change only recognizes the response sent by a JGit based server. All
other servers which report such problems in a different way still lead
to a generic TransportExceptions.

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

Allow users to provide their OutputStream (via Transport#
push(monitor, refUpdates, out)) so that server messages can be written
to it (in SideBandInputStream) while they're coming in.

CQ: 7065
Bug: 398404
Change-Id: I670782784b38702d52bca98203909aca0496d1c0
Signed-off-by: Andre Dietisheim <andre.dietisheim@gmail.com>
Signed-off-by: Chris Aniszczyk <zx@twitter.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

- Translate internal exceptions to corresponding API exception
- Do not catch GitAPI exceptions internally to an internal
exception. Just pass them to caller
- Mention thrown exceptions in javadoc

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

All commands should throw a GitAPIException so new exceptions can be
added without breaking the builds of old code, i.e. anyone that calls
a Git API should catch GitAPIException and not just the currently known
exceptions.

Now the only checked exceptions on Git API calls are GitException and
subclasses of it. New checked exceptions that are subclasses of
GitException may be added without breaking the API.

Javadoc for GitAPIException is declared on GitCommand and
inherited to subclasses. JGitInternalException is not explicitly
documented anymore.

Unfortunately this change itself breaks the API. The intention is
that it shall be possible to add new checked subclasses of
GitAPIException without breaking the API.

Bug: 366914
EGit-Change-Id: I50380f13fc82c22d0036f47c7859cc3a77e767c5
Change-Id: I50380f13fc82c22d0036f47c7859cc3a77e767c5
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>

Change-Id: I763590a45d75f00a09097ab6f89581a3bbd3c797

Refactored the three common transport configuration options:
credentials provider, timeout, and transport config callback
into a new TransportCommand base class which is now extended
by all commands that use a Transport object during execution.

Bug: 349188
Change-Id: I90c2c14fb4e3cc4712905158f9047153a0c235c2
Signed-off-by: Kevin Sawicki <kevin@github.com>
Signed-off-by: Chris Aniszczyk <zx@twitter.com>

Add a TransportConfigCallback parameter to JGit API commands, to allow
consumers of the JGit command API to perform custom Transport configuration
that would be otherwise difficult to anticipate & expose on the API command
builders.


My specific use-case is configuring additional properties on SshTransport
- I need to take over the SshSessionFactory used by the transport. Using
TransportConfigCallback I can simply do this (rather than reimplement the
API command classes):

public void configure(Transport tn) {
  if (tn instanceof SshTransport) {
    ((SshTransport) tn).setSshSessionFactory(factoryProvider.get());
  }
}

Adding an explicit setSshSessionFactory() method to the JGit command
classes would bloat the API. Also, creating the replacement
SshSessionFactory is unnecessary if the transport is not SSH, but the type
of the Transport is only known once the remote has been resolved and the
URI parsed - consequently it makes sense to perform this step in a
callback, where the transport instance can be inspected to determine if
it's of a relevant type.


A note about where this leaves the API - there are now 4 commands:

CloneCommand
PullCommand
FetchCommand
PushCommand

-that share 3 identical transport-related parameters:

timeout
credentialsProvider
transportConfigurator

I think there's potential for introducing an interface or val-object to
identify/encapsulate this repetition, which I'd be happy to do in a
subsequent commit.

Change-Id: I8983c3627cdd7d7b2aeb0b6a3dadee553378b951
Signed-off-by: Roberto Tyley <roberto.tyley@gmail.com>

If no refSpec is explicitly set, the PushCommand should first check the
remote config and then as a fallback use the current behavior.


Change-Id: I2bc648abc517b1d01b2de15d383423ace2081e72
Signed-off-by: Stefan Lay <stefan.lay@sap.com>

The simplified form of add(String) makes it easier for applications
to pass down user input and allow PushCommand to convert it to the
internal RefSpec object.

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

The --all flag on the command line implies using refs/heads/* as
a push specification. Add this to the standard command object.

The --tags flag on the command line implies using refs/tags/* as
a push specification. Add this to the standard command object.

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

If no RefSpec was specified, push the branch that is currently
checked out as HEAD.

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

Rather than copying the entire list, just replace each element
with the version that has setForceUpdate(true) invoked on it.

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

PushCommand now does not set a null credentials provider on
Transport because in this case the default provider is replaced with
null and the default mechanism for providing credentials is not
working.

Bug: 336023
Change-Id: I7a7a9221afcfebe2e1595a5e59641e6c1ae4a207
Signed-off-by: Jens Baumgart <jens.baumgart@sap.com>

Change-Id: I984836ea7d6a67fd2d1d05f270afa7c29f30971c
Signed-off-by: Mathias Kinzler <mathias.kinzler@sap.com>

This is needed for commands that use Transport internally.

Change-Id: I9417c85255b160723968c647063b9c7e05995ea4
Signed-off-by: Mathias Kinzler <mathias.kinzler@sap.com>
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>

Change-Id: Iff144a51fdc9a1112a21492c390a873a2b293bc9
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>

FetchCommand was missing the ability to set dry run and thin
preferences on the transport operation.

Change-Id: I0bef388a9b8f2e3a01ecc9e7782aaed7f9ac82ce
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>

Adds API for performing git fetch operations.

Change-Id: Idd95664fd4e3bca03211e4ffda3e354849f92a35
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>