Skip to main content
aboutsummaryrefslogtreecommitdiffstats
path: root/org.eclipse.jgit/src/org/eclipse/jgit/JGitText.java
AgeCommit message (Collapse)AuthorFilesLines
2011-11-23Guard against null branch in PullCommandKevin Sawicki1-0/+1
Throw a NoHeadException when Repository.getFullBranch returns null Bug: 351543 Change-Id: I666cd5b67781508a293ae553c6fe5c080c8f4d99 Signed-off-by: Kevin Sawicki <kevin@github.com>
2011-11-22maxObjectSizeLimit for receive-pack.Sasa Zivkov1-0/+2
ReceivePack (and PackParser) can be configured with the maxObjectSizeLimit in order to prevent users from pushing too large objects to Git. The limit check is applied to all object types although it is most likely that a BLOB will exceed the limit. In all cases the size of the object header is excluded from the object size which is checked against the limit as this is the size of which a BLOB object would take in the working tree when checked out as a file. When an object exceeds the maxObjectSizeLimit the receive-pack will abort immediately. Delta objects (both offset and ref delta) are also checked against the limit. However, for delta objects we will first check the size of the inflated delta block against the maxObjectSizeLimit and abort immediately if it exceeds the limit. In this case we even do not know the exact size of the resolved delta object but we assume it will be larger than the given maxObjectSizeLimit as delta is generally only chosen if the delta can copy more data from the base object than the delta needs to insert or needs to represent the copy ranges. Aborting early, in this case, avoids unnecessary inflating of the (huge) delta block. Unfortunately, it is too expensive (especially for a large delta) to compute SHA-1 of an object that causes the receive-pack to abort. This would decrease the value of this feature whose main purpose is to protect server resources from users pushing huge objects. Therefore we don't report the SHA-1 in the error message. Change-Id: I177ef24553faacda444ed5895e40ac8925ca0d1e Signed-off-by: Sasa Zivkov <sasa.zivkov@sap.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2011-11-14Add an object encapsulating the state of a PackWriterDave Borowitz1-0/+1
Exposes essentially the same state machine to the programmer as is exposed to the client via a ProgressMonitor, using a wrapper around beginTask()/endTask(). Change-Id: Ic3622b4acea65d2b9b3551c668806981fa7293e3
2011-10-26Cosmetic adjustment of relative date format, do not display "0 months"Robin Rosenberg1-0/+1
Though it may seem less precise, "0 months" looks bad and the reference Git implementation also does not display "0 months" Change-Id: I488e9c97656f9941788ae88d7c5c1562ab6c26f0
2011-08-24Use JGitText.refAlreadyExists instead of "ref exists"Tomasz Zarna1-1/+1
Change-Id: I113bcf82c6292db5269271f799d09c80acc40bcd
2011-08-21Add DeleteTagCommand to JGit APITomasz Zarna1-0/+1
Bug: 353226 Change-Id: I54ae237cab792742333a249eb5a774d5e1775af8 Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
2011-08-17Adds DiffEntry.scan(TreeWalk, boolean) methodDariusz Luksza1-0/+2
Adds method into DiffEntry class that allows to specify whether changed trees are included in scanning result list. By default changed trees aren't added, but in some cases having changed tree would be useful. Also adds check for tree count in TreeWalk and when it is different from two it will thrown an IllegalArgumentException. This change is required by egit I7ddb21e7ff54333dd6d7ace3209bbcf83da2b219 Change-Id: I5a680a73e1cffa18ade3402cc86008f46c1da1f1 Signed-off-by: Dariusz Luksza <dariusz@luksza.org> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2011-07-06Cloning should fail when destination directory exists and is not emptyAdrian Goerler1-0/+1
When trying to clone into a folder that already contains a cloned repository native git will fail with a message "fatal: destination path 'folder' already exists and is not an empty directory.". Now JGit will also fail in this situation throwing a JGitInternalException. The test case was provided by Tomasz Zarna. Bug: 347852 Change-Id: If9e9919a5f92d13cf038dc470c21ee5967322dac Also-by: Tomasz Zarna <Tomasz.Zarna@pl.ibm.com> Signed-off-by: Adrian Goerler <adrian.goerler@sap.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2011-06-10Push errors back over sideband when possibleShawn O. Pearce1-0/+1
If an internal exception occurs while packing and the request needs to abort, the HTTP response might already be committed due to progress message having already been delivered to the client. This prevents UploadPackServlet from resetting the response and sending back an HTTP 500 response. Try to catch all exceptions and report internal errors over the sideband stream or as an ERR command during the initial ACK/NAK negotiation phase. This allows JGit to transmit an error message that the user will receive on their console without needing to worry about resetting the (already gone) HTTP response. Change-Id: Ie393fb8bb55d2b79ab1276adf71c781c1807f9fe Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2011-06-10Report progress while updating referencesShawn O. Pearce1-0/+1
If a fetch or push needs to apply more than a few references to the local repository it may take more than 0.25 seconds to process all of the updates. This is especially true in the DHT storage system during an initial push of a project with many tags. The backend database may need to use a transaction to ensure each tag reference creation is unique, and there may be large delays caused by these transactions. Change-Id: Ib11a077adfbd525253e425d327f2e2c2380804c7 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2011-05-31blame: Compute the origin of lines in a result fileShawn O. Pearce1-0/+1
BlameGenerator digs through history and discovers the origin of each line of some result file. BlameResult consumes the stream of regions created by the generator and lays them out in a table for applications to display alongside of source lines. Applications may optionally push in the working tree copy of a file using the push(String, byte[]) method, allowing the application to receive accurate line annotations for the working tree version. Lines that are uncommitted (difference between HEAD and working tree) will show up with the description given by the application as the author, or "Not Committed Yet" as a default string. Applications may also run the BlameGenerator in reverse mode using the reverse(AnyObjectId, AnyObjectId) method instead of push(). When running in the reverse mode the generator annotates lines by the commit they are removed in, rather than the commit they were added in. This allows a user to discover where a line disappeared from when they are looking at an older revision in the repository. For example: blame --reverse 16e810b2..master -L 1080, org.eclipse.jgit.test/tst/org/eclipse/jgit/storage/file/RefDirectoryTest.java ( 1080) } 2302a6d3 (Christian Halstrick 2011-05-20 11:18:20 +0200 1081) 2302a6d3 (Christian Halstrick 2011-05-20 11:18:20 +0200 1082) /** 2302a6d3 (Christian Halstrick 2011-05-20 11:18:20 +0200 1083) * Kick the timestamp of a local file. Above we learn that line 1080 (a closing curly brace of the prior method) still exists in branch master, but the Javadoc comment below it has been removed by Christian Halstrick on May 20th as part of commit 2302a6d3. This result differs considerably from that of C Git's blame --reverse feature. JGit tells the reader which commit performed the delete, while C Git tells the reader the last commit that still contained the line, leaving it an exercise to the reader to discover the descendant that performed the removal. This is still only a basic implementation. Quite notably it is missing support for the smart block copy/move detection that the C implementation of `git blame` is well known for. Despite being incremental, the BlameGenerator can only be run once. After the generator runs it cannot be reused. A better implementation would support applications browsing through history efficiently. In regards to CQ 5110, only a little of the original code survives. CQ: 5110 Bug: 306161 Change-Id: I84b8ea4838bb7d25f4fcdd540547884704661b8f Signed-off-by: Kevin Sawicki <kevin@github.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
2011-05-19Add LsRemoteCommand to JGit APIChristoph Brill1-0/+1
Bug: 343801 Change-Id: Ic651e8e09143e15ed459461b50b2222e13da56c4 Also-by: Chris Aniszczyk <caniszczyk@gmail.com> Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
2011-05-09Formatter for relative datesMatthias Sohn1-0/+13
Change-Id: I78b307177c68c578e10101a0ee7b6306880a08f7 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2011-04-01PackWriter: Remove dummy list 0Shawn O. Pearce1-1/+0
Instead of looping over the objectsLists array, always set slot 0 to null and explicitly work on the 4 indexes that matter. This kills some loops and increases the length of the code slightly, but I've always really disliked that dummy 0 slot. Change-Id: I5ad938501c1c61f637ffdaff0d0d88e3962d8942 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2011-03-17UploadPack: Report invalid want lines with ERRShawn O. Pearce1-1/+1
Instead of aborting hard with a server-side exception, report an error to the client with "ERR %s" in a context where the client is expecting ACK/NAK. Older clients will report this text to the user, but newer ones know how to format this message in a more user-friendly way. Change-Id: I1879b38988ba66f648c069c10dbfa14c3f34adb2 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2011-03-15Replace 'occured' by 'occurred'Philipp Thun1-2/+2
This change fixes a common typo. Signed-off-by: Philipp Thun <philipp.thun@sap.com>
2011-03-13Make the supported Transports extensible and discoverableShawn O. Pearce1-0/+8
The new TransportProtocol type describes what a particular Transport implementation wants in order to support a connection. 3rd parties can now plug into the Transport.open() logic by implementing their own TransportProtocol and Transport classes, and registering with Transport.register(). GUI applications can help the user configure a connection by looking at the supported fields of a particular TransportProtocol type, which makes the GUI more dynamic and may better support new Transports. Change-Id: Iafd8e3a6285261412aac6cba8e2c333f8b7b76a5 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2011-03-11Add -o option to commit commandPhilipp Thun1-0/+2
This change adds the --only/ -o option to the commit command. Change-Id: I44352d56877f8204d985cb7a35a2e0faffb7d341 Signed-off-by: Philipp Thun <philipp.thun@sap.com>
2011-02-17Add git-reset to the Git APIChris Aniszczyk1-0/+1
Bug: 334764 Change-Id: Ice404629687d7f2a595d8d4eccf471b12f7e32ec Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
2011-02-15daemon: Use HTTP's resolver and factory patternShawn O. Pearce1-0/+2
Using a resolver and factory pattern for the anonymous git:// Daemon class makes transport.Daemon more useful on non-file storage systems, or in embedded applications where the caller wants more precise control over the work tasks constructed within the daemon. Rather than defining new interfaces, move the existing HTTP ones into transport.resolver and make them generic on the connection handle type. For HTTP, continue to use HttpServletRequest, and for transport.Daemon use DaemonClient. To remain compatible with transport.Daemon, FileResolver needs to learn how to use multiple base directories, and how to export any Repository instance at a fixed name. Change-Id: I1efa6b2bd7c6567e983fbbf346947238ea2e847e Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2011-02-03PackWriter: Support reuse of entire packsShawn O. Pearce1-0/+1
The most expensive part of packing a repository for transport to another system is enumerating all of the objects in the repository. Once this gets to the size of the linux-2.6 repository (1.8 million objects), enumeration can take several CPU minutes and costs a lot of temporary working set memory. Teach PackWriter to efficiently reuse an existing "cached pack" by answering a clone request with a thin pack followed by a larger cached pack appended to the end. This requires the repository owner to first construct the cached pack by hand, and record the tip commits inside of $GIT_DIR/objects/info/cached-packs: cd $GIT_DIR root=$(git rev-parse master) tmp=objects/.tmp-$$ names=$(echo $root | git pack-objects --keep-true-parents --revs $tmp) for n in $names; do chmod a-w $tmp-$n.pack $tmp-$n.idx touch objects/pack/pack-$n.keep mv $tmp-$n.pack objects/pack/pack-$n.pack mv $tmp-$n.idx objects/pack/pack-$n.idx done (echo "+ $root"; for n in $names; do echo "P $n"; done; echo) >>objects/info/cached-packs git repack -a -d When a clone request needs to include $root, the corresponding cached pack will be copied as-is, rather than enumerating all of the objects that are reachable from $root. For a linux-2.6 kernel repository that should be about 376 MiB, the above process creates two packs of 368 MiB and 38 MiB[1]. This is a local disk usage increase of ~26 MiB, due to reduced delta compression between the large cached pack and the smaller recent activity pack. The overhead is similar to 1 full copy of the compressed project sources. With this cached pack in hand, JGit daemon completes a clone request in 1m17s less time, but a slightly larger data transfer (+2.39 MiB): Before: remote: Counting objects: 1861830, done remote: Finding sources: 100% (1861830/1861830) remote: Getting sizes: 100% (88243/88243) remote: Compressing objects: 100% (88184/88184) Receiving objects: 100% (1861830/1861830), 376.01 MiB | 19.01 MiB/s, done. remote: Total 1861830 (delta 4706), reused 1851053 (delta 1553844) Resolving deltas: 100% (1564621/1564621), done. real 3m19.005s After: remote: Counting objects: 1601, done remote: Counting objects: 1828460, done remote: Finding sources: 100% (50475/50475) remote: Getting sizes: 100% (18843/18843) remote: Compressing objects: 100% (7585/7585) remote: Total 1861830 (delta 2407), reused 1856197 (delta 37510) Receiving objects: 100% (1861830/1861830), 378.40 MiB | 31.31 MiB/s, done. Resolving deltas: 100% (1559477/1559477), done. real 2m2.938s Repository owners can periodically refresh their cached packs by repacking their repository, folding all newer objects into a larger cached pack. Since repacking is already considered to be a normal Git maintenance activity, this isn't a very big burden. [1] In this test $root was set back about two weeks. Change-Id: Ib87131d5c4b5e8c5cacb0f4fe16ff4ece554734b Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2011-02-03PackWriter: Display totals after sending objectsShawn O. Pearce1-0/+1
CGit pack-objects displays a totals line after the pack data was fully written. This can be useful to understand some of the decisions made by the packer, and has been a great tool for helping to debug some of that code. Track some of the basic values, and send it to the client when packing is done: remote: Counting objects: 1826776, done remote: Finding sources: 100% (55121/55121) remote: Getting sizes: 100% (25654/25654) remote: Compressing objects: 100% (11434/11434) remote: Total 1861830 (delta 3926), reused 1854705 (delta 38306) Receiving objects: 100% (1861830/1861830), 386.03 MiB | 30.32 MiB/s, done. Change-Id: If3b039017a984ed5d5ae80940ce32bda93652df5 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2011-02-01PackWriter: Correct 'Compressing objects' progress messageShawn O. Pearce1-0/+1
The first 'Compressing objects' progress message is wrong, its actually PackWriter looking up the sizes of each object in the ObjectDatabase, so objects can be sorted correctly in the later type-size sort that tries to take advantage of "Linus' Law" to improve delta compression. Rename the progress to say 'Getting sizes', which is an accurate description of what it is doing. Change-Id: Ida0a052ad2f6e994996189ca12959caab9e556a3 Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
2011-01-31Proper handling of rebase during pullMathias Kinzler1-0/+1
After consulting with Christian Halstrick, it turned out that the handling of rebase during pull was implemented incorrectly. Change-Id: I40f03409e080cdfeceb21460150f5e02a016e7f4 Signed-off-by: Mathias Kinzler <mathias.kinzler@sap.com>
2011-01-21Introduce metaData compare between working tree and index entriesChristian Halstrick1-0/+1
Instead of offering only a high-level isModified() method a new method compareMetadata() is introduced which compares a working tree entry and a index entry by looking at metadata only. Some use-cases (e.g. computing the content-id in idBuffer()) may use this new method instead of isModified(). Change-Id: I4de7501d159889fbac5ae6951f4fef8340461b47 Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
2011-01-14File utility for creating a new empty fileMatthias Sohn1-0/+1
The java.io.File.createNewFile() method for creating new empty files reports failure by returning false. To ease proper checking of return values provide a utility method wrapping createNewFile() throwing IOException on failure. Change-Id: I42a3dc9d8ff70af62e84de396e6a740050afa896 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2011-01-08Merging Git notesSasa Zivkov1-0/+2
Merging Git notes branches has several differences from merging "normal" branches. Although Git notes are initially stored as one flat tree the tree may fanout when the number of notes becomes too large for efficient access. In this case the first two hex digits of the note name will be used as a subdirectory name and the rest 38 hex digits as the file name under that directory. Similarly, when number of notes decreases a fanout tree may collapse back into a flat tree. The Git notes merge algorithm must take into account possibly different tree structures in different note branches and must properly match them against each other. Any conflict on a Git note is, by default, resolved by concatenating the two conflicting versions of the note. A delete-edit conflict is, by default, resolved by keeping the edit version. The note merge logic is pluggable and the caller may provide custom note merger that will perform different merging strategy. Additionally, it is possible to have non-note entries inside a notes tree. The merge algorithm must also take this fact into account and will try to merge such non-note entries. However, in case of any merge conflicts the merge operation will fail. Git notes merge algorithm is currently not trying to do content merge of non-note entries. Thanks to Shawn Pearce for patiently answering my questions related to this topic, giving hints and providing code snippets. Change-Id: I3b2335c76c766fd7ea25752e54087f9b19d69c88 Signed-off-by: Sasa Zivkov <sasa.zivkov@sap.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2011-01-02Implement a revert commandRobin Rosenberg1-0/+2
This is almost reverted cherry-pick, and the implementation is almost identical. It orders the input to merge differently to get the effect and produces a different commit message with the default author, rather than the original author. Change-Id: I39970091d9f7406ae7168b8efaab23a5e2c16bad Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
2010-12-31Add support for getting the system wide configurationRobin Rosenberg1-0/+1
These settings are stored in <prefix>/etc/gitconfig. The C Git binary is installed in <prefix>/bin, so we look for the C Git executable to find this location, first by looking at the PATH environment variable and then by attemting to launch bash as a login shell to find out. Bug: 333216 Change-Id: I1bbee9fb123a81714a34a9cc242b92beacfbb4a8 Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
2010-12-13File utilities for creating directoriesMatthias Sohn1-1/+3
The java.io.File methods for creating directories report failure by returning false. To ease proper checking of return values provide utility methods wrapping mkdir() and mkdirs() which throw IOException on failure. Also fix the tests to store test data under a trash folder and cleanup after test. Change-Id: I09c7f9909caf7e25feabda9d31e21ce154e7fcd5 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com> Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
2010-12-09Implement rebase --continue and --skipMathias Kinzler1-0/+2
For --continue, the Rebase command asserts that there are no unmerged paths in the current repository. Then it checks if a commit is needed. If yes, the commit message and author are taken from the author_script and message files, respectively, and a commit is performed before the next step is applied. For --skip, the workspace is reset to the current HEAD before applying the next step. Includes some tests and a refactoring that extracts Strings in the code into constants. Change-Id: I72d9968535727046e737ec20e23239fe79976179 Signed-off-by: Mathias Kinzler <mathias.kinzler@sap.com> Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
2010-12-08Provide file utilities for file deletionMatthias Sohn1-1/+2
Provide file helper methods in a reusable utility class to replace many local implementations. java.io.File has some methods reporting failure by returning false. We prefer to throw IOException on failure so that callers can't forget checking the return value. Change-Id: I430c77b5d2cffcf8b47584326ad4817a7291845e Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2010-11-24Add more tests for rebase and externalized missing StringsChristian Halstrick1-0/+1
Coverage tests showed that we are missing to test certain areas in the rebase command. Add the missing tests. Change-Id: Ia4a272d26cde7e1861dac30496e4b6799fc8187a Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
2010-11-22Add CheckoutCommandChris Aniszczyk1-0/+1
Add the ability to checkout a branch to the working tree. Bug: 330860 Change-Id: Ie06b9e799a9e1be384da0b8996efa7209b32eac3 Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
2010-11-22Add RmCommand to Git APIChris Aniszczyk1-0/+1
Bug: 330827 Change-Id: I0b74bb92254d0ee988139d25022d06d16ed89d58 Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
2010-11-22Initial implementation of a Rebase commandMathias Kinzler1-0/+7
This is a first iteration to implement Rebase. At the moment, this does not implement --continue and --skip, so if the first conflict is found, the only option is to --abort the command. Bug: 328217 Change-Id: I24d60c0214e71e5572955f8261e10a42e9e95298 Signed-off-by: Mathias Kinzler <mathias.kinzler@sap.com> Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
2010-11-10Enable providing credentials for HTTP authenticationShawn O. Pearce1-1/+2
This change is based on http://egit.eclipse.org/r/#change,1652 by David Green. The change adds the concept of a CredentialsProvider which can be registered for git transports and which is responsible to return credential-related data like passwords and usernames. Whenenver the transports detects that an authentication with certain credentials has to be done it will ask the CredentialsProvider for this data. Foreseen implementations for such a Provider may be a EGitCredentialsProvider (caching credential data entered e.g. in the Clone-Wizzard) or a NetRcProvider (gathering data out of ~/.netrc file). Bug: 296201 Change-Id: Ibe13e546b45eed3e193c09ecb414bbec2971d362 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com> Signed-off-by: Christian Halstrick <christian.halstrick@sap.com> Signed-off-by: Stefan Lay <stefan.lay@sap.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org> CC: David Green <dgreen99@gmail.com>
2010-10-28PullCommand: support upstream configuration for local branchesMathias Kinzler1-0/+1
When creating a local branch based on another local branch, the upstream configuration contains "." as origin and the source branch as "merge". The PullCommand should support this by skipping the fetch step altogether and use the base branch to merge with. Change-Id: I260a1771aeeffca5b0161d1494fd63c672ecc2a6 Signed-off-by: Mathias Kinzler <mathias.kinzler@sap.com>
2010-10-15Add Cherry-Pick commandChristian Halstrick1-0/+2
Implemented the initial version of a cherry-pick command. A correct error handling is missing (what happens if the checkout fails, the cherry-pick leads to conflicts etc). But straightforward cherry-picks works. Change-Id: I235c0eb3a7a2d5bdfe40400f1deed06f29d746e1 Signed-off-by: Christian Halstrick <christian.halstrick@sap.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2010-10-10Add "Branch" commandMathias Kinzler1-0/+11
The need for branching becomes more pressing with pull support: we need to make sure the upstream configuration entries are written correctly when creating and renaming branches (and of course are cleaned up when deleting them). This adds support for listing, adding, deleting and renaming branches including the more common options. Bug: 326938 Change-Id: I00bcc19476e835d6fd78fd188acde64946c1505c Signed-off-by: Mathias Kinzler <mathias.kinzler@sap.com> Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
2010-10-08Add "Pull" commandMathias Kinzler1-0/+6
This is the minimal implementation of a "Pull" command. It does not have any parameters besides the generic progress monitor and timeout. It works on the currently checked-out branch and assumes that the configuration contains the keys "branch.<branch name>.remote" and "branch.<branch name>.merge" to determine the remote configuration for the fetch and the remote branch name for the merge. Bug: 303404 Change-Id: I7fe09029996d0cfc09a7d8f097b5d6af1488fa93 Signed-off-by: Mathias Kinzler <mathias.kinzler@sap.com> Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
2010-10-07Externalize strings in TransportHttpMatthias Sohn1-0/+3
Some strings were not externalized. Also use them in HTTP tests to ensure that they will also succeed when message bundles are translated. Change-Id: Id02717176557e7d57e676e1339cd89f2be88d330 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
2010-10-05Add PushCommand APIChris Aniszczyk1-1/+2
Change-Id: Iff144a51fdc9a1112a21492c390a873a2b293bc9 Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
2010-10-04Increase core.streamFileThreshold default to 50 MiBShawn O. Pearce1-0/+1
Projects like org.eclipse.mdt contain large XML files about 6 MiB in size. So does the Android project platform/frameworks/base. Doing a clone of either project with JGit takes forever to checkout the files into the working directory, because delta decompression tends to be very expensive as we need to constantly reposition the base stream for each copy instruction. This can be made worse by a very bad ordering of offsets, possibly due to an XML editor that doesn't preserve the order of elements in the file very well. Increasing the threshold to the same limit PackWriter uses when doing delta compression (50 MiB) permits a default configured JGit to decompress these XML file objects using the faster random-access arrays, rather than re-seeking through an inflate stream, significantly reducing checkout time after a clone. Since this new limit may be dangerously close to the JVM maximum heap size, every allocation attempt is now wrapped in a try/catch so that JGit can degrade by switching to the large object stream mode when the allocation is refused. It will run slower, but the operation will still complete. The large stream mode will run very well for big objects that aren't delta compressed, and is acceptable for delta compressed objects that are using only forward referencing copy instructions. Copies using prior offsets are still going to be horrible, and there is nothing we can do about it except increase core.streamFileThreshold. We might in the future want to consider changing the way the delta generators work in JGit and native C Git to avoid prior offsets once an object reaches a certain size, even if that causes the delta instruction stream to be slightly larger. Unfortunately native C Git won't want to do that until its also able to stream objects rather than malloc them as contiguous blocks. Change-Id: Ief7a3896afce15073e80d3691bed90c6a3897307 Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
2010-09-25Implement HistogramDiffShawn O. Pearce1-0/+1
HistogramDiff is an alternative implementation of patience diff, performing a search over all matching locations and picking the longest common subsequence that has the lowest occurrence count. If there are unique common elements, its behavior is identical to that of patience diff. Actual performance on real-world source files usually beats MyersDiff, sometimes by a factor of 3, especially for complex comparators that ignore whitespace. Change-Id: I1806cd708087e36d144fb824a0e5ab7cdd579d73 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-09-17Add FetchCommandChris Aniszczyk1-0/+2
Adds API for performing git fetch operations. Change-Id: Idd95664fd4e3bca03211e4ffda3e354849f92a35 Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
2010-09-08Support core.autocrlf = inputShawn O. Pearce1-0/+3
The core.autocrlf variable can take on three values: false, true, and input. Parsing it as a boolean is wrong, we instead need to parse a tri-state enumeration. Add support for parsing and setting enum values from Java from and to the text based configuration file, and use that to handle the autocrlf variable. Bug: 301775 Change-Id: I81b9e33087a33d2ef2eac89ba93b9e83b7ecc223 Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-09-03Merge branch 'unpack-error'Shawn O. Pearce1-0/+1
* unpack-error: ReceivePack: Rethrow exceptions caught during indexing Change-Id: I0d0239d69cb5cd1a622bdee879978f0299e0ca40
2010-09-03ReceivePack: Rethrow exceptions caught during indexingShawn O. Pearce1-0/+1
If we get an exception while indexing the incoming pack, its likely a stream corruption. We already report an error to the client, but we eat the stack trace, which makes debugging issues related to a bug inside of JGit nearly impossible. Rethrow it under a new type UnpackException, so embedding servers or applications can catch the error and provide it to a human who might be able to forward such traces onto a JGit developer for evaluation. Change-Id: Icad41148bbc0c76f284c7033a195a6b51911beab Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2010-08-31Partial support for index file format "3".Marc Strapetz1-0/+1
Extended flags are processed and available via DirCacheEntry's new isSkipWorkTree() and isIntentToAdd() methods. "resolve-undo" information is completely ignored since its an optional extension. Change-Id: Ie6e9c6784c9f265ca3c013c6dc0e6bd29d3b7233

Back to the top