You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

JGitText.properties 48KB

Support creating pack bitmap indexes in PackWriter. Update the PackWriter to support writing out pack bitmap indexes, a parallel ".bitmap" file to the ".pack" file. Bitmaps are selected at commits every 1 to 5,000 commits for each unique path from the start. The most recent 100 commits are all bitmapped. The next 19,000 commits have a bitmaps every 100 commits. The remaining commits have a bitmap every 5,000 commits. Commits with more than 1 parent are prefered over ones with 1 or less. Furthermore, previously computed bitmaps are reused, if the previous entry had the reuse flag set, which is set when the bitmap was placed at the max allowed distance. Bitmaps are used to speed up the counting phase when packing, for requests that are not shallow. The PackWriterBitmapWalker uses a RevFilter to proactively mark commits with RevFlag.SEEN, when they appear in a bitmap. The walker produces the full closure of reachable ObjectIds, given the collection of starting ObjectIds. For fetch request, two ObjectWalks are executed to compute the ObjectIds reachable from the haves and from the wants. The ObjectIds needed to be written are determined by taking all the resulting wants AND NOT the haves. For clone requests, we get cached pack support for "free" since it is possible to determine if all of the ObjectIds in a pack file are included in the resulting list of ObjectIds to write. On my machine, the best times for clones and fetches of the linux kernel repository (with about 2.6M objects and 300K commits) are tabulated below: Operation Index V2 Index VE003 Clone 37530ms (524.06 MiB) 82ms (524.06 MiB) Fetch (1 commit back) 75ms 107ms Fetch (10 commits back) 456ms (269.51 KiB) 341ms (265.19 KiB) Fetch (100 commits back) 449ms (269.91 KiB) 337ms (267.28 KiB) Fetch (1000 commits back) 2229ms ( 14.75 MiB) 189ms ( 14.42 MiB) Fetch (10000 commits back) 2177ms ( 16.30 MiB) 254ms ( 15.88 MiB) Fetch (100000 commits back) 14340ms (185.83 MiB) 1655ms (189.39 MiB) Change-Id: Icdb0cdd66ff168917fb9ef17b96093990cc6a98d
11 years ago
blame: Compute the origin of lines in a result file 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>
13 years ago
Support creating pack bitmap indexes in PackWriter. Update the PackWriter to support writing out pack bitmap indexes, a parallel ".bitmap" file to the ".pack" file. Bitmaps are selected at commits every 1 to 5,000 commits for each unique path from the start. The most recent 100 commits are all bitmapped. The next 19,000 commits have a bitmaps every 100 commits. The remaining commits have a bitmap every 5,000 commits. Commits with more than 1 parent are prefered over ones with 1 or less. Furthermore, previously computed bitmaps are reused, if the previous entry had the reuse flag set, which is set when the bitmap was placed at the max allowed distance. Bitmaps are used to speed up the counting phase when packing, for requests that are not shallow. The PackWriterBitmapWalker uses a RevFilter to proactively mark commits with RevFlag.SEEN, when they appear in a bitmap. The walker produces the full closure of reachable ObjectIds, given the collection of starting ObjectIds. For fetch request, two ObjectWalks are executed to compute the ObjectIds reachable from the haves and from the wants. The ObjectIds needed to be written are determined by taking all the resulting wants AND NOT the haves. For clone requests, we get cached pack support for "free" since it is possible to determine if all of the ObjectIds in a pack file are included in the resulting list of ObjectIds to write. On my machine, the best times for clones and fetches of the linux kernel repository (with about 2.6M objects and 300K commits) are tabulated below: Operation Index V2 Index VE003 Clone 37530ms (524.06 MiB) 82ms (524.06 MiB) Fetch (1 commit back) 75ms 107ms Fetch (10 commits back) 456ms (269.51 KiB) 341ms (265.19 KiB) Fetch (100 commits back) 449ms (269.91 KiB) 337ms (267.28 KiB) Fetch (1000 commits back) 2229ms ( 14.75 MiB) 189ms ( 14.42 MiB) Fetch (10000 commits back) 2177ms ( 16.30 MiB) 254ms ( 15.88 MiB) Fetch (100000 commits back) 14340ms (185.83 MiB) 1655ms (189.39 MiB) Change-Id: Icdb0cdd66ff168917fb9ef17b96093990cc6a98d
11 years ago
PackWriter: Support reuse of entire packs 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>
13 years ago
Persist filesystem timestamp resolution and allow manual configuration To enable persisting filesystem timestamp resolution per FileStore add a new config section to the user global git configuration: - Config section is "filesystem" - Config subsection is concatenation of - Java vendor (system property "java.vm.vendor") - runtime version (system property "java.vm.version") - FileStore's name - separated by '|' e.g. "AdoptOpenJDK|1.8.0_212-b03|/dev/disk1s1" The prefix is needed since some Java versions do not expose the full timestamp resolution of the underlying filesystem. This may also depend on the underlying operating system hence concrete key values may not be portable. - Config key for timestamp resolution is "timestampResolution" as a time value, supported time units are those supported by DefaultTypedConfigGetter#getTimeUnit If timestamp resolution is already configured for a given FileStore the configured value is used instead of measuring the resolution. When timestamp resolution was measured it is persisted in the user global git configuration. Example: [filesystem "AdoptOpenJDK|1.8.0_212-b03|/dev/disk1s1"] timestampResolution = 1 seconds If locking the git config file fails retry saving the resolution up to 5 times in order to workaround races with another thread. In order to avoid stack overflow use the fallback filesystem timestamp resolution when loading FileBasedConfig which creates itself a FileSnapshot to help checking if the config changed. Note: - on some OSes Java 8,9 truncate to milliseconds or seconds, see https://bugs.openjdk.java.net/browse/JDK-8177809, fixed in Java 10 - UnixFileAttributes up to Java 12 truncates timestamp resolution to microseconds when converting the internal representation to FileTime exposed in the API, see https://bugs.openjdk.java.net/browse/JDK-8181493 - WindowsFileAttributes also provides only microsecond resolution up to Java 12 Hence do not attempt to manually configure a higher timestamp resolution than supported by the Java version being used at runtime. Bug: 546891 Bug: 548188 Change-Id: Iff91b8f9e6e5e2295e1463f87c8e95edf4abbcf8 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
4 years ago
Fix atomic lock file creation on NFS FS_POSIX.createNewFile(File) failed to properly implement atomic file creation on NFS using the algorithm [1]: - name of the hard link must be unique to prevent that two processes using different NFS clients try to create the same link. This would render nlink useless to detect if there was a race. - the hard link must be retained for the lifetime of the file since we don't know when the state of the involved NFS clients will be synchronized. This depends on NFS configuration options. To fix these issues we need to change the signature of createNewFile which would break API. Hence deprecate the old method FS.createNewFile(File) and add a new method createNewFileAtomic(File). The new method returns a LockToken which needs to be retained by the caller (LockFile) until all involved NFS clients synchronized their state. Since we don't know when the NFS caches are synchronized we need to retain the token until the corresponding file is no longer needed. The LockToken must be closed after the LockFile using it has been committed or unlocked. On Posix, if core.supportsAtomicCreateNewFile = false this will delete the hard link which guarded the atomic creation of the file. When acquiring the lock fails ensure that the hard link is removed. [1] https://www.time-travellers.org/shane/papers/NFS_considered_harmful.html also see file creation flag O_EXCL in http://man7.org/linux/man-pages/man2/open.2.html Change-Id: I84fcb16143a5f877e9b08c6ee0ff8fa4ea68a90d Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
5 years ago
Config: Rewrite subsection and value escaping and parsing Previously, Config was using the same method for both escaping and parsing subsection names and config values. The goal was presumably code savings, but unfortunately, these two pieces of the git config format are simply different. In git v2.15.1, Documentation/config.txt says the following about subsection names: "Subsection names are case sensitive and can contain any characters except newline (doublequote `"` and backslash can be included by escaping them as `\"` and `\\`, respectively). Section headers cannot span multiple lines. Variables may belong directly to a section or to a given subsection." And, later in the same documentation section, about values: "A line that defines a value can be continued to the next line by ending it with a `\`; the backquote and the end-of-line are stripped. Leading whitespaces after 'name =', the remainder of the line after the first comment character '#' or ';', and trailing whitespaces of the line are discarded unless they are enclosed in double quotes. Internal whitespaces within the value are retained verbatim. Inside double quotes, double quote `"` and backslash `\` characters must be escaped: use `\"` for `"` and `\\` for `\`. The following escape sequences (beside `\"` and `\\`) are recognized: `\n` for newline character (NL), `\t` for horizontal tabulation (HT, TAB) and `\b` for backspace (BS). Other char escape sequences (including octal escape sequences) are invalid." The main important differences are that subsection names have a limited set of supported escape sequences, and do not support newlines at all, either escaped or unescaped. Arguably, it would be easy to support escaped newlines, but C git simply does not: $ git config -f foo.config $'foo.bar\nbaz.quux' value error: invalid key (newline): foo.bar baz.quux I468106ac was an attempt to fix one bug in escapeValue, around leading whitespace, without having to rewrite the whole escaping/parsing code. Unfortunately, because escapeValue was used for escaping subsection names as well, this made it possible to write invalid config files, any time Config#toText is called with a subsection name with trailing whitespace, like {foo }. Rather than pile hacks on top of hacks, fix it for real by largely rewriting the escaping and parsing code. In addition to fixing escape sequences, fix (and write tests for) a few more issues in the old implementation: * Now that we can properly parse it, always emit newlines as "\n" from escapeValue, rather than the weird (but still supported) syntax with a non-quoted trailing literal "\n\" before the newline. In addition to producing more readable output and matching the behavior of C git, this makes the escaping code much simpler. * Disallow '\0' entirely within both subsection names and values, since due to Unix command line argument conventions it is impossible to pass such values to "git config". * Properly preserve intra-value whitespace when parsing, rather than collapsing it all to a single space. Change-Id: I304f626b9d0ad1592c4e4e449a11b136c0f8b3e3
6 years ago
Retry stale file handles on .git/config file On a local non-NFS filesystem the .git/config file will be orphaned if it is replaced by a new process while the current process is reading the old file. The current process successfully continues to read the orphaned file until it closes the file handle. Since NFS servers do not keep track of open files, instead of orphaning the old .git/config file, such a replacement on an NFS filesystem will instead cause the old file to be garbage collected (deleted). A stale file handle exception will be raised on NFS clients if the file is garbage collected (deleted) on the server while it is being read. Since we no longer have access to the old file in these cases, the previous code would just fail. However, in these cases, reopening the file and rereading it will succeed (since it will open the new replacement file). Since retrying the read is a viable strategy to deal with stale file handles on the .git/config file, implement such a strategy. Since it is possible that the .git/config file could be replaced again while rereading it, loop on stale file handle exceptions, up to 5 extra times, trying to read the .git/config file again, until we either read the new file, or find that the file no longer exists. The limit of 5 is arbitrary, and provides a safe upper bounds to prevent infinite loops consuming resources in a potential unforeseen persistent error condition. Change-Id: I6901157b9dfdbd3013360ebe3eb40af147a8c626 Signed-off-by: Nasser Grainawi <nasser@codeaurora.org> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
6 years ago
Client-side protocol V2 support for fetching Make all transports request protocol V2 when fetching. Depending on the transport, set the GIT_PROTOCOL environment variable (file and ssh), pass the Git-Protocol header (http), or set the hidden "\0version=2\0" (git anon). We'll fall back to V0 if the server doesn't reply with a version 2 answer. A user can control which protocol the client requests via the git config protocol.version; if not set, JGit requests protocol V2 for fetching. Pushing always uses protocol V0 still. In the API, there is only a new Transport.openFetch() version that takes a collection of RefSpecs plus additional patterns to construct the Ref prefixes for the "ls-refs" command in protocol V2. If none are given, the server will still advertise all refs, even in protocol V2. BasePackConnection.readAdvertisedRefs() handles falling back to protocol V0. It newly returns true if V0 was used and the advertised refs were read, and false if V2 is used and an explicit "ls-refs" is needed. (This can't be done transparently inside readAdvertisedRefs() because a "stateless RPC" transport like TransportHttp may need to open a new connection for writing.) BasePackFetchConnection implements the changes needed for the protocol V2 "fetch" command (stateless protocol, simplified ACK handling, delimiters, section headers). In TransportHttp, change readSmartHeaders() to also recognize the "version 2" packet line as a valid smart server indication. Adapt tests, and run all the HTTP tests not only with both HTTP connection factories (JDK and Apache HttpClient) but also with both protocol V0 and V2. The SSH tests are much slower and much more focused on the SSH protocol and SSH key handling. Factor out two very simple cloning and pulling tests and make those run with protocol V2. Bug: 553083 Change-Id: I357c7f5daa7efb2872f1c64ee6f6d54229031ae1 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
3 years ago
Added read/write support for pack bitmap index. A pack bitmap index is an additional index of compressed bitmaps of the object graph. Furthermore, a logical API of the index functionality is included, as it is expected to be used by the PackWriter. Compressed bitmaps are created using the javaewah library, which is a word-aligned compressed variant of the Java bitset class based on run-length encoding. The library only works with positive integer values. Thus, the maximum number of ObjectIds in a pack file that this index can currently support is limited to Integer.MAX_VALUE. Every ObjectId is given an integer mapping. The integer is the position of the ObjectId in the complete ObjectId list, sorted by offset, for the pack file. That integer is what the bitmaps use to reference the ObjectId. Currently, the new index format can only be used with pack files that contain a complete closure of the object graph e.g. the result of a garbage collection. The index file includes four bitmaps for the Git object types i.e. commits, trees, blobs, and tags. In addition, a collection of bitmaps keyed by an ObjectId is also included. The bitmap for each entry in the collection represents the full closure of ObjectIds reachable from the keyed ObjectId (including the keyed ObjectId itself). The bitmaps are further compressed by XORing the current bitmaps against prior bitmaps in the index, and selecting the smallest representation. The XOR'd bitmap and offset from the current entry to the position of the bitmap to XOR against is the actual representation of the entry in the index file. Each entry contains one byte, which is currently used to note whether the bitmap should be blindly reused. Change-Id: Id328724bf6b4c8366a088233098c18643edcf40f
11 years ago
Support http.<url>.* configs Git has a rather elaborate mechanism to specify HTTP configuration options per URL, based on pattern matching the URL against "http" subsection names.[1] The URLs used for this matching are always the original URLs; redirected URLs do not participate. * Scheme and host must match exactly case-insensitively. * An optional user name must match exactly. * Ports must match exactly after default ports have been filled in. * The path of a subsection, if any, must match a segment prefix of the path of the URL. * Matches with user name take precedence over equal-length path matches without, but longer path matches are preferred over shorter matches with user name. Implement this for JGit. Factor out the HttpConfig from TransportHttp and implement the matching and override mechanism. The set of supported settings is still the same; JGit currently supports only followRedirects, postBuffer, and sslVerify, plus the JGit-specific maxRedirects key. Add tests for path normalization and prefix matching only on segment separators, and use the new mechanism in SmartClientSmartServerSslTest to disable sslVerify selectively for only the test server URLs. Compare also bug 374703 and bug 465492. With this commit it would be possible to set sslVerify to false for only the git server using a self-signed certificate instead of having to switch it off globally via http.sslVerify. [1] https://git-scm.com/docs/git-config Change-Id: I42a3c2399cb937cd7884116a2a32fcaa7a418fcb Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
TransportHttp: shared SSLContext during fetch or push TransportHttp makes several HTTP requests. The SSLContext and socket factory must be shared over these requests, otherwise authentication information may not be propagated correctly from one request to the next. This is important for authentication mechanisms that rely on client-side state, like NEGOTIATE (either NTLM, if the underlying HTTP library supports it, or Kerberos). In particular, SPNEGO cannot authenticate on a POST request; the authentication must come from the initial GET request, which implies that the POST request must use the same SSLContext and socket factory that was used for the GET. Change the way HTTPS connections are configured. Introduce the concept of a GitSession, which is a client-side HTTP session over several HTTPS requests. TransportHttp creates such a session and uses it to configure all HTTP requests during that session (fetch or push). This gives a way to abstract away the differences between JDK and Apache HTTP connections and to configure SSL setup outside. A GitSession can maintain state and thus give all HTTP requests in a session the same socket factory. Introduce an extension interface HttpConnectionFactory2 that adds a method to obtain a new GitSession. Implement this for both existing HTTP connection factories. Change TransportHttp to use the new GitSession to configure HTTP connections. The old methods for disabling SSL verification still exist to support possibly external connection and connection factory implementations that do not make use of the new GitSession yet. Bug: 535850 Change-Id: Iedf67464e4e353c1883447c13c86b5a838e678f1 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
3 years ago
Add support to follow HTTP redirects git-core follows HTTP redirects so JGit should also provide this. Implement config setting http.followRedirects with possible values "false" (= never), "true" (= always), and "initial" (only on GET, but not on POST).[1] We must do our own redirect handling and cannot rely on the support that the underlying real connection may offer. At least the JDK's HttpURLConnection has two features that get in the way: * it does not allow cross-protocol redirects and thus fails on http->https redirects (for instance, on Github). * it translates a redirect after a POST to a GET unless the system property "http.strictPostRedirect" is set to true. We don't want to manipulate that system setting nor require it. Additionally, git has its own rules about what redirects it accepts;[2] for instance, it does not allow a redirect that adds query arguments. We handle response codes 301, 302, 303, and 307 as per RFC 2616.[3] On POST we do not handle 303, and we follow redirects only if http.followRedirects == true. Redirects are followed only a certain number of times. There are two ways to control that limit: * by default, the limit is given by the http.maxRedirects system property that is also used by the JDK. If the system property is not set, the default is 5. (This is much lower than the JDK default of 20, but I don't see the value of following so many redirects.) * this can be overwritten by a http.maxRedirects git config setting. The JGit http.* git config settings are currently all global; JGit has no support yet for URI-specific settings "http.<pattern>.name". Adding support for that is well beyond the scope of this change. Like git-core, we log every redirect attempt (LOG.info) so that users may know about the redirection having occurred. Extends the test framework to configure an AppServer with HTTPS support so that we can test cloning via HTTPS and redirections involving HTTPS. [1] https://git-scm.com/docs/git-config [2] https://kernel.googlesource.com/pub/scm/git/git/+/6628eb41db5189c0cdfdced6d8697e7c813c5f0f [3] https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html CQ: 13987 Bug: 465167 Change-Id: I86518cb76842f7d326b51f8715e3bbf8ada89859 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com> Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
9 years ago
Merging Git notes 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>
13 years ago
Make blame work correctly on merge conflicts When a conflicting file was blamed, JGit would not identify lines coming from the merge parents. The main cause for this was that Blame and BlameCommand simply added the first DirCacheEntry found for a file to its queue of candidates (blobs or commits) to consider. In case of a conflict this typically is the merge base commit, and comparing a auto-merged contents against that base would yield incorrect results. Such cases have to be handled specially. The candidate to be considered by the blame must use the working tree contents, but at the same time behave like a merge commit/candidate with HEAD and the MERGE_HEADs as parents. Canonical git does something very similar, see [1]. Implement that and add tests. I first did this for the JGit pgm Blame command. When I then tried to do the same in BlameCommand, I noticed that the latter also included some fancy but incomplete CR-LF handling. In order to be able to use the new BlameGenerator.prepareHead() also in BlameCommand this CR-LF handling was also moved into BlameGenerator and corrected in doing so. (Just considering the git config settings was not good enough, CR-LF behavior can also be influenced by .gitattributes, and even by whether the file in the index has CR-LF. To correctly determine CR-LF handling for check-in one needs to do a TreeWalk with at least a FileTreeIterator and a DirCacheIterator.) [1] https://github.com/git/git/blob/v2.22.0/blame.c#L174 Bug: 434330 Change-Id: I9d763dd6ba478b0b6ebf9456049d6301f478ef7c Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
4 years ago
Added read/write support for pack bitmap index. A pack bitmap index is an additional index of compressed bitmaps of the object graph. Furthermore, a logical API of the index functionality is included, as it is expected to be used by the PackWriter. Compressed bitmaps are created using the javaewah library, which is a word-aligned compressed variant of the Java bitset class based on run-length encoding. The library only works with positive integer values. Thus, the maximum number of ObjectIds in a pack file that this index can currently support is limited to Integer.MAX_VALUE. Every ObjectId is given an integer mapping. The integer is the position of the ObjectId in the complete ObjectId list, sorted by offset, for the pack file. That integer is what the bitmaps use to reference the ObjectId. Currently, the new index format can only be used with pack files that contain a complete closure of the object graph e.g. the result of a garbage collection. The index file includes four bitmaps for the Git object types i.e. commits, trees, blobs, and tags. In addition, a collection of bitmaps keyed by an ObjectId is also included. The bitmap for each entry in the collection represents the full closure of ObjectIds reachable from the keyed ObjectId (including the keyed ObjectId itself). The bitmaps are further compressed by XORing the current bitmaps against prior bitmaps in the index, and selecting the smallest representation. The XOR'd bitmap and offset from the current entry to the position of the bitmap to XOR against is the actual representation of the entry in the index file. Each entry contains one byte, which is currently used to note whether the bitmap should be blindly reused. Change-Id: Id328724bf6b4c8366a088233098c18643edcf40f
11 years ago
Handle stale file handles on packed-refs file On a local filesystem the packed-refs file will be orphaned if it is replaced by another client while the current client is reading the old one. However, since NFS servers do not keep track of open files, instead of orphaning the old packed-refs file, such a replacement will cause the old file to be garbage collected instead. A stale file handle exception will be raised on NFS servers if the file is garbage collected (deleted) on the server while it is being read. Since we no longer have access to the old file in these cases, the previous code would just fail. However, in these cases, reopening the file and rereading it will succeed (since it will reopen the new replacement file). So retrying the read is a viable strategy to deal with stale file handles on the packed-refs file, implement such a strategy. Since it is possible that the packed-refs file could be replaced again while rereading it (multiple consecutive updates can easily occur with ref deletions), loop on stale file handle exceptions, up to 5 extra times, trying to read the packed-refs file again, until we either read the new file, or find that the file no longer exists. The limit of 5 is arbitrary, and provides a safe upper bounds to prevent infinite loops consuming resources in a potential unforeseen persistent error condition. Change-Id: I085c472bafa6e2f32f610a33ddc8368bb4ab1814 Signed-off-by: Martin Fick<mfick@codeaurora.org> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
8 years ago
Rewrite push certificate parsing - Consistently return structured data, such as actual ReceiveCommands, which is more useful for callers that are doing things other than verifying the signature, e.g. recording the set of commands. - Store the certificate version field, as this is required to be part of the signed payload. - Add a toText() method to recreate the actual payload for signature verification. This requires keeping track of the un-chomped command strings from the original protocol stream. - Separate the parser from the certificate itself, so the actual PushCertificate object can be immutable. Make a fair attempt at deep immutability, but this is not possible with the current mutable ReceiveCommand structure. - Use more detailed error messages that don't involve NON-NLS strings. - Document null return values more thoroughly. Instead of having the undocumented behavior of throwing NPE from certain methods if they are not first guarded by enabled(), eliminate enabled() and return null from those methods. - Add tests for parsing a push cert from a section of pkt-line stream using a real live stream captured with Wireshark (which, it should be noted, uncovered several simply incorrect statements in C git's Documentation/technical/pack-protocol.txt). This is a slightly breaking API change to classes that were technically public and technically released in 4.0. However, it is highly unlikely that people were actually depending on public behavior, since there were no public methods to create PushCertificates with anything other than null field values, or a PushCertificateParser that did anything other than infinite loop or throw exceptions when reading. Change-Id: I5382193347a8eb1811032d9b32af9651871372d0
9 years ago
Persist filesystem timestamp resolution and allow manual configuration To enable persisting filesystem timestamp resolution per FileStore add a new config section to the user global git configuration: - Config section is "filesystem" - Config subsection is concatenation of - Java vendor (system property "java.vm.vendor") - runtime version (system property "java.vm.version") - FileStore's name - separated by '|' e.g. "AdoptOpenJDK|1.8.0_212-b03|/dev/disk1s1" The prefix is needed since some Java versions do not expose the full timestamp resolution of the underlying filesystem. This may also depend on the underlying operating system hence concrete key values may not be portable. - Config key for timestamp resolution is "timestampResolution" as a time value, supported time units are those supported by DefaultTypedConfigGetter#getTimeUnit If timestamp resolution is already configured for a given FileStore the configured value is used instead of measuring the resolution. When timestamp resolution was measured it is persisted in the user global git configuration. Example: [filesystem "AdoptOpenJDK|1.8.0_212-b03|/dev/disk1s1"] timestampResolution = 1 seconds If locking the git config file fails retry saving the resolution up to 5 times in order to workaround races with another thread. In order to avoid stack overflow use the fallback filesystem timestamp resolution when loading FileBasedConfig which creates itself a FileSnapshot to help checking if the config changed. Note: - on some OSes Java 8,9 truncate to milliseconds or seconds, see https://bugs.openjdk.java.net/browse/JDK-8177809, fixed in Java 10 - UnixFileAttributes up to Java 12 truncates timestamp resolution to microseconds when converting the internal representation to FileTime exposed in the API, see https://bugs.openjdk.java.net/browse/JDK-8181493 - WindowsFileAttributes also provides only microsecond resolution up to Java 12 Hence do not attempt to manually configure a higher timestamp resolution than supported by the Java version being used at runtime. Bug: 546891 Bug: 548188 Change-Id: Iff91b8f9e6e5e2295e1463f87c8e95edf4abbcf8 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
4 years ago
maxObjectSizeLimit for receive-pack. 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>
12 years ago
Add support to follow HTTP redirects git-core follows HTTP redirects so JGit should also provide this. Implement config setting http.followRedirects with possible values "false" (= never), "true" (= always), and "initial" (only on GET, but not on POST).[1] We must do our own redirect handling and cannot rely on the support that the underlying real connection may offer. At least the JDK's HttpURLConnection has two features that get in the way: * it does not allow cross-protocol redirects and thus fails on http->https redirects (for instance, on Github). * it translates a redirect after a POST to a GET unless the system property "http.strictPostRedirect" is set to true. We don't want to manipulate that system setting nor require it. Additionally, git has its own rules about what redirects it accepts;[2] for instance, it does not allow a redirect that adds query arguments. We handle response codes 301, 302, 303, and 307 as per RFC 2616.[3] On POST we do not handle 303, and we follow redirects only if http.followRedirects == true. Redirects are followed only a certain number of times. There are two ways to control that limit: * by default, the limit is given by the http.maxRedirects system property that is also used by the JDK. If the system property is not set, the default is 5. (This is much lower than the JDK default of 20, but I don't see the value of following so many redirects.) * this can be overwritten by a http.maxRedirects git config setting. The JGit http.* git config settings are currently all global; JGit has no support yet for URI-specific settings "http.<pattern>.name". Adding support for that is well beyond the scope of this change. Like git-core, we log every redirect attempt (LOG.info) so that users may know about the redirection having occurred. Extends the test framework to configure an AppServer with HTTPS support so that we can test cloning via HTTPS and redirections involving HTTPS. [1] https://git-scm.com/docs/git-config [2] https://kernel.googlesource.com/pub/scm/git/git/+/6628eb41db5189c0cdfdced6d8697e7c813c5f0f [3] https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html CQ: 13987 Bug: 465167 Change-Id: I86518cb76842f7d326b51f8715e3bbf8ada89859 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com> Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
9 years ago
RenameBranchCommand: more consistent handling of short ref names Several problems: * The command didn't specify whether it expected short or full names. * For the new name, it expected a short name, but then got confused if tags or both local and remote branches with the same name existed. * For the old name, it accepted either a short or a full name, but again got confused if a short name was given and a tag with the same name existed. With such an interface, one cannot use Repository.findRef() to reliably find the branch to rename. Use exactRef() for the new name as by the time the Ref is needed its full name is known. For determining the old Ref from the name, do the resolution explicitly: first try exactRef (assuming the old name is a full name); if that doesn't find anything, try "refs/heads/<old>" and "refs/remotes/<old>" explicitly. Throw an exception if the name is ambiguous, or if exactRef returned something that is not a branch (refs/tags/... or also refs/notes/...). Document in the javadoc what kind of names are valid, and add tests. A user can still shoot himself in the foot if he chooses exceptionally stupid branch names. For instance, it is still possible to rename a branch to "refs/heads/foo" (full name "refs/heads/refs/heads/foo"), but it cannot be renamed further using the new short name if a branch with the full name "refs/heads/foo" exists. Similar edge cases exist for other dumb branch names, like a branch with the short name "refs/tags/foo". Renaming using the full name is always possible. Bug: 542446 Change-Id: I34ac91c80c0a00c79a384d16ce1e727c550d54e9 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
5 years ago
Implement similarity based rename detection Content similarity based rename detection is performed only after a linear time detection is performed using exact content match on the ObjectIds. Any names which were paired up during that exact match phase are excluded from the inexact similarity based rename, which reduces the space that must be considered. During rename detection two entries cannot be marked as a rename if they are different types of files. This prevents a symlink from being renamed to a regular file, even if their blob content appears to be similar, or is identical. Efficiently comparing two files is performed by building up two hash indexes and hashing lines or short blocks from each file, counting the number of bytes that each line or block represents. Instead of using a standard java.util.HashMap, we use a custom open hashing scheme similiar to what we use in ObjecIdSubclassMap. This permits us to have a very light-weight hash, with very little memory overhead per cell stored. As we only need two ints per record in the map (line/block key and number of bytes), we collapse them into a single long inside of a long array, making very efficient use of available memory when we create the index table. We only need object headers for the index structure itself, and the index table, but not per-cell. This offers a massive space savings over using java.util.HashMap. The score calculation is done by approximating how many bytes are the same between the two inputs (which for a delta would be how much is copied from the base into the result). The score is derived by dividing the approximate number of bytes in common into the length of the larger of the two input files. Right now the SimilarityIndex table should average about 1/2 full, which means we waste about 50% of our memory on empty entries after we are done indexing a file and sort the table's contents. If memory becomes an issue we could discard the table and copy all records over to a new array that is properly sized. Building the index requires O(M + N log N) time, where M is the size of the input file in bytes, and N is the number of unique lines/blocks in the file. The N log N time constraint comes from the sort of the index table that is necessary to perform linear time matching against another SimilarityIndex created for a different file. To actually perform the rename detection, a SxD matrix is created, placing the sources (aka deletions) along one dimension and the destinations (aka additions) along the other. A simple O(S x D) loop examines every cell in this matrix. A SimilarityIndex is built along the row and reused for each column compare along that row, avoiding the costly index rebuild at the row level. A future improvement would be to load a smaller square matrix into SimilarityIndexes and process everything in that sub-matrix before discarding the column dimension and moving down to the next sub-matrix block along that same grid of rows. An optional ProgressMonitor is permitted to be passed in, allowing applications to see the progress of the detector as it works through the matrix cells. This provides some indication of current status for very long running renames. The default line/block hash function used by the SimilarityIndex may not be optimal, and may produce too many collisions. It is borrowed from RawText's hash, which is used to quickly skip out of a longer equality test if two lines have different hash functions. We may need to refine this hash in the future, in order to minimize the number of collisions we get on common source files. Based on a handful of test commits in JGit (especially my own recent rename repository refactoring series), this rename detector produces output that is very close to C Git. The content similarity scores are sometimes off by 1%, which is most probably caused by our SimilarityIndex type using a different hash function than C Git uses when it computes the delta size between any two objects in the rename matrix. Bug: 318504 Change-Id: I11dff969e8a2e4cf252636d857d2113053bdd9dc Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
14 years ago
Increase core.streamFileThreshold default to 50 MiB 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>
13 years ago
Support creating pack bitmap indexes in PackWriter. Update the PackWriter to support writing out pack bitmap indexes, a parallel ".bitmap" file to the ".pack" file. Bitmaps are selected at commits every 1 to 5,000 commits for each unique path from the start. The most recent 100 commits are all bitmapped. The next 19,000 commits have a bitmaps every 100 commits. The remaining commits have a bitmap every 5,000 commits. Commits with more than 1 parent are prefered over ones with 1 or less. Furthermore, previously computed bitmaps are reused, if the previous entry had the reuse flag set, which is set when the bitmap was placed at the max allowed distance. Bitmaps are used to speed up the counting phase when packing, for requests that are not shallow. The PackWriterBitmapWalker uses a RevFilter to proactively mark commits with RevFlag.SEEN, when they appear in a bitmap. The walker produces the full closure of reachable ObjectIds, given the collection of starting ObjectIds. For fetch request, two ObjectWalks are executed to compute the ObjectIds reachable from the haves and from the wants. The ObjectIds needed to be written are determined by taking all the resulting wants AND NOT the haves. For clone requests, we get cached pack support for "free" since it is possible to determine if all of the ObjectIds in a pack file are included in the resulting list of ObjectIds to write. On my machine, the best times for clones and fetches of the linux kernel repository (with about 2.6M objects and 300K commits) are tabulated below: Operation Index V2 Index VE003 Clone 37530ms (524.06 MiB) 82ms (524.06 MiB) Fetch (1 commit back) 75ms 107ms Fetch (10 commits back) 456ms (269.51 KiB) 341ms (265.19 KiB) Fetch (100 commits back) 449ms (269.91 KiB) 337ms (267.28 KiB) Fetch (1000 commits back) 2229ms ( 14.75 MiB) 189ms ( 14.42 MiB) Fetch (10000 commits back) 2177ms ( 16.30 MiB) 254ms ( 15.88 MiB) Fetch (100000 commits back) 14340ms (185.83 MiB) 1655ms (189.39 MiB) Change-Id: Icdb0cdd66ff168917fb9ef17b96093990cc6a98d
11 years ago
Do authentication re-tries on HTTP POST There is at least one git server out there (GOGS) that does not require authentication on the initial GET for info/refs?service=git-receive-pack but that _does_ require authentication for the subsequent POST to actually do the push. This occurs on GOGS with public repositories; for private repositories it wants authentication up front. Handle this behavior by adding 401 handling to our POST request. Note that this is suboptimal; we'll re-send the push data at least twice if an authentication failure on POST occurs. It would be much better if the server required authentication up-front in the GET request. Added authentication unit tests (using BASIC auth) to the SmartClientSmartServerTest: - clone with authentication - clone with authentication but lacking CredentialsProvider - clone with authentication and wrong password - clone with authentication after redirect - clone with authentication only on POST, but not on GET Also tested manually in the wild using repositories at try.gogs.io. That server offers only BASIC auth, so the other paths (DIGEST, NEGOTIATE, fall back from DIGEST to BASIC) are untested and I have no way to test them. * public repository: GET unauthenticated, POST authenticated Also tested after clearing the credentials and then entering a wrong password: correctly asks three times during the HTTP POST for user name and password, then gives up. * private repository: authentication already on GET; then gets applied correctly initially to the POST request, which succeeds. Also fix the authentication to use the credentials for the redirected URI if redirects had occurred. We must not present the credentials for the original URI in that case. Consider a malicious redirect A->B: this would allow server B to harvest the user credentials for server A. The unit test for authentication after a redirect also tests for this. Bug: 513043 Change-Id: I97ee5058569efa1545a6c6f6edfd2b357c40592a Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
6 years ago
Shallow fetch: Respect "shallow" lines When fetching from a shallow clone, the client sends "have" lines to tell the server about objects it already has and "shallow" lines to tell where its local history terminates. In some circumstances, the server fails to honor the shallow lines and fails to return objects that the client needs. UploadPack passes the "have" lines to PackWriter so PackWriter can omit them from the generated pack. UploadPack processes "shallow" lines by calling RevWalk.assumeShallow() with the set of shallow commits. RevWalk creates and caches RevCommits for these shallow commits, clearing out their parents. That way, walks correctly terminate at the shallow commits instead of assuming the client has history going back behind them. UploadPack converts its RevWalk to an ObjectWalk, maintaining the cached RevCommits, and passes it to PackWriter. Unfortunately, to support shallow fetches the PackWriter does the following: if (shallowPack && !(walk instanceof DepthWalk.ObjectWalk)) walk = new DepthWalk.ObjectWalk(reader, depth); That is, when the client sends a "deepen" line (fetch --depth=<n>) and the caller has not passed in a DepthWalk.ObjectWalk, PackWriter throws away the RevWalk that was passed in and makes a new one. The cleared parent lists prepared by RevWalk.assumeShallow() are lost. Fortunately UploadPack intends to pass in a DepthWalk.ObjectWalk. It tries to create it by calling toObjectWalkWithSameObjects() on a DepthWalk.RevWalk. But it doesn't work: because DepthWalk.RevWalk does not override the standard RevWalk#toObjectWalkWithSameObjects implementation, the result is a plain ObjectWalk instead of an instance of DepthWalk.ObjectWalk. The result is that the "shallow" information is thrown away and objects reachable from the shallow commits can be omitted from the pack sent when fetching with --depth from a shallow clone. Multiple factors collude to limit the circumstances under which this bug can be observed: 1. Commits with depth != 0 don't enter DepthGenerator's pending queue. That means a "have" cannot have any effect on DepthGenerator unless it is also a "want". 2. DepthGenerator#next() doesn't call carryFlagsImpl(), so the uninteresting flag is not propagated to ancestors there even if a "have" is also a "want". 3. JGit treats a depth of 1 as "1 past the wants". Because of (2), the only place the UNINTERESTING flag can leak to a shallow commit's parents is in the carryFlags() call from markUninteresting(). carryFlags() only traverses commits that have already been parsed: commits yet to be parsed are supposed to inherit correct flags from their parent in PendingGenerator#next (which doesn't happen here --- that is (2)). So the list of commits that have already been parsed becomes relevant. When we hit the markUninteresting() call, all "want"s, "have"s, and commits to be unshallowed have been parsed. carryFlags() only affects the parsed commits. If the "want" is a direct parent of a "have", then it carryFlags() marks it as uninteresting. If the "have" was also a "shallow", then its parent pointer should have been null and the "want" shouldn't have been marked, so we see the bug. If the "want" is a more distant ancestor then (2) keeps the uninteresting state from propagating to the "want" and we don't see the bug. If the "shallow" is not also a "have" then the shallow commit isn't parsed so (2) keeps the uninteresting state from propagating to the "want so we don't see the bug. Here is a reproduction case (time flowing left to right, arrows pointing to parents). "C" must be a commit that the client reports as a "have" during negotiation. That can only happen if the server reports it as an existing branch or tag in the first round of negotiation: A <-- B <-- C <-- D First do git clone --depth 1 <repo> which yields D as a "have" and C as a "shallow" commit. Then try git fetch --depth 1 <repo> B:refs/heads/B Negotiation sets up: have D, shallow C, have C, want B. But due to this bug B is marked as uninteresting and is not sent. Change-Id: I6e14b57b2f85e52d28cdcf356df647870f475440 Signed-off-by: Terry Parker <tparker@google.com>
7 years ago
GPG signature verification via BouncyCastle Add a GpgSignatureVerifier interface, plus a factory to create instances thereof that is provided via the ServiceLoader mechanism. Implement the new interface for BouncyCastle. A verifier maintains an internal LRU cache of previously found public keys to speed up verifying multiple objects (tag or commits). Mergetags are not handled. Provide a new VerifySignatureCommand in org.eclipse.jgit.api together with a factory method Git.verifySignature(). The command can verify signatures on tags or commits, and can be limited to accept only tags or commits. Provide a new public WrongObjectTypeException thrown when the command is limited to either tags or commits and a name resolves to some other object kind. In jgit.pgm, implement "git tag -v", "git log --show-signature", and "git show --show-signature". The output is similar to command-line gpg invoked via git, but not identical. In particular, lines are not prefixed by "gpg:" but by "bc:". Trust levels for public keys are read from the keys' trust packets, not from GPG's internal trust database. A trust packet may or may not be set. Command-line GPG produces more warning lines depending on the trust level, warning about keys with a trust level below "full". There are no unit tests because JGit still doesn't have any setup to do signing unit tests; this would require at least a faked .gpg directory with pre-created key rings and keys, and a way to make the BouncyCastle classes use that directory instead of the default. See bug 547538 and also bug 544847. Tested manually with a small test repository containing signed and unsigned commits and tags, with signatures made with different keys and made by command-line git using GPG 2.2.25 and by JGit using BouncyCastle 1.65. Bug: 547751 Change-Id: If7e34aeed6ca6636a92bf774d893d98f6d459181 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
3 years ago
Implement similarity based rename detection Content similarity based rename detection is performed only after a linear time detection is performed using exact content match on the ObjectIds. Any names which were paired up during that exact match phase are excluded from the inexact similarity based rename, which reduces the space that must be considered. During rename detection two entries cannot be marked as a rename if they are different types of files. This prevents a symlink from being renamed to a regular file, even if their blob content appears to be similar, or is identical. Efficiently comparing two files is performed by building up two hash indexes and hashing lines or short blocks from each file, counting the number of bytes that each line or block represents. Instead of using a standard java.util.HashMap, we use a custom open hashing scheme similiar to what we use in ObjecIdSubclassMap. This permits us to have a very light-weight hash, with very little memory overhead per cell stored. As we only need two ints per record in the map (line/block key and number of bytes), we collapse them into a single long inside of a long array, making very efficient use of available memory when we create the index table. We only need object headers for the index structure itself, and the index table, but not per-cell. This offers a massive space savings over using java.util.HashMap. The score calculation is done by approximating how many bytes are the same between the two inputs (which for a delta would be how much is copied from the base into the result). The score is derived by dividing the approximate number of bytes in common into the length of the larger of the two input files. Right now the SimilarityIndex table should average about 1/2 full, which means we waste about 50% of our memory on empty entries after we are done indexing a file and sort the table's contents. If memory becomes an issue we could discard the table and copy all records over to a new array that is properly sized. Building the index requires O(M + N log N) time, where M is the size of the input file in bytes, and N is the number of unique lines/blocks in the file. The N log N time constraint comes from the sort of the index table that is necessary to perform linear time matching against another SimilarityIndex created for a different file. To actually perform the rename detection, a SxD matrix is created, placing the sources (aka deletions) along one dimension and the destinations (aka additions) along the other. A simple O(S x D) loop examines every cell in this matrix. A SimilarityIndex is built along the row and reused for each column compare along that row, avoiding the costly index rebuild at the row level. A future improvement would be to load a smaller square matrix into SimilarityIndexes and process everything in that sub-matrix before discarding the column dimension and moving down to the next sub-matrix block along that same grid of rows. An optional ProgressMonitor is permitted to be passed in, allowing applications to see the progress of the detector as it works through the matrix cells. This provides some indication of current status for very long running renames. The default line/block hash function used by the SimilarityIndex may not be optimal, and may produce too many collisions. It is borrowed from RawText's hash, which is used to quickly skip out of a longer equality test if two lines have different hash functions. We may need to refine this hash in the future, in order to minimize the number of collisions we get on common source files. Based on a handful of test commits in JGit (especially my own recent rename repository refactoring series), this rename detector produces output that is very close to C Git. The content similarity scores are sometimes off by 1%, which is most probably caused by our SimilarityIndex type using a different hash function than C Git uses when it computes the delta size between any two objects in the rename matrix. Bug: 318504 Change-Id: I11dff969e8a2e4cf252636d857d2113053bdd9dc Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
14 years ago
Handle SSL handshake failures in TransportHttp When a https connection could not be established because the SSL handshake was unsuccessful, TransportHttp would unconditionally throw a TransportException. Other https clients like web browsers or also some SVN clients handle this more gracefully. If there's a problem with the server certificate, they inform the user and give him a possibility to connect to the server all the same. In git, this would correspond to dynamically setting http.sslVerify to false for the server. Implement this using the CredentialsProvider to inform and ask the user. We offer three choices: 1. skip SSL verification for the current git operation, or 2. skip SSL verification for the server always from now on for requests originating from the current repository, or 3. always skip SSL verification for the server from now on. For (1), we just suppress SSL verification for the current instance of TransportHttp. For (2), we store a http.<uri>.sslVerify = false setting for the original URI in the repo config. For (3), we store the http.<uri>.sslVerify setting in the git user config. Adapt the SmartClientSmartServerSslTest such that it uses this mechanism instead of setting http.sslVerify up front. Improve SimpleHttpServer to enable setting it up also with HTTPS support in anticipation of an EGit SWTbot UI test verifying that cloning via HTTPS from a server that has a certificate that doesn't validate pops up the correct dialog, and that cloning subsequently proceeds successfully if the user decides to skip SSL verification. Bug: 374703 Change-Id: Ie1abada9a3d389ad4d8d52c2d5265d2764e3fb0e Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
6 years ago
Fix atomic lock file creation on NFS FS_POSIX.createNewFile(File) failed to properly implement atomic file creation on NFS using the algorithm [1]: - name of the hard link must be unique to prevent that two processes using different NFS clients try to create the same link. This would render nlink useless to detect if there was a race. - the hard link must be retained for the lifetime of the file since we don't know when the state of the involved NFS clients will be synchronized. This depends on NFS configuration options. To fix these issues we need to change the signature of createNewFile which would break API. Hence deprecate the old method FS.createNewFile(File) and add a new method createNewFileAtomic(File). The new method returns a LockToken which needs to be retained by the caller (LockFile) until all involved NFS clients synchronized their state. Since we don't know when the NFS caches are synchronized we need to retain the token until the corresponding file is no longer needed. The LockToken must be closed after the LockFile using it has been committed or unlocked. On Posix, if core.supportsAtomicCreateNewFile = false this will delete the hard link which guarded the atomic creation of the file. When acquiring the lock fails ensure that the hard link is removed. [1] https://www.time-travellers.org/shane/papers/NFS_considered_harmful.html also see file creation flag O_EXCL in http://man7.org/linux/man-pages/man2/open.2.html Change-Id: I84fcb16143a5f877e9b08c6ee0ff8fa4ea68a90d Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
5 years ago
GPG signature verification via BouncyCastle Add a GpgSignatureVerifier interface, plus a factory to create instances thereof that is provided via the ServiceLoader mechanism. Implement the new interface for BouncyCastle. A verifier maintains an internal LRU cache of previously found public keys to speed up verifying multiple objects (tag or commits). Mergetags are not handled. Provide a new VerifySignatureCommand in org.eclipse.jgit.api together with a factory method Git.verifySignature(). The command can verify signatures on tags or commits, and can be limited to accept only tags or commits. Provide a new public WrongObjectTypeException thrown when the command is limited to either tags or commits and a name resolves to some other object kind. In jgit.pgm, implement "git tag -v", "git log --show-signature", and "git show --show-signature". The output is similar to command-line gpg invoked via git, but not identical. In particular, lines are not prefixed by "gpg:" but by "bc:". Trust levels for public keys are read from the keys' trust packets, not from GPG's internal trust database. A trust packet may or may not be set. Command-line GPG produces more warning lines depending on the trust level, warning about keys with a trust level below "full". There are no unit tests because JGit still doesn't have any setup to do signing unit tests; this would require at least a faked .gpg directory with pre-created key rings and keys, and a way to make the BouncyCastle classes use that directory instead of the default. See bug 547538 and also bug 544847. Tested manually with a small test repository containing signed and unsigned commits and tags, with signatures made with different keys and made by command-line git using GPG 2.2.25 and by JGit using BouncyCastle 1.65. Bug: 547751 Change-Id: If7e34aeed6ca6636a92bf774d893d98f6d459181 Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
3 years ago
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789790791792793794795796797798799800801802803804805806807808809810811812813814815816817
  1. #
  2. # Messages with format elements ({0}) are processed using java.text.MessageFormat.
  3. #
  4. abbreviationLengthMustBeNonNegative=Abbreviation length must not be negative.
  5. abortingRebase=Aborting rebase: resetting to {0}
  6. abortingRebaseFailed=Could not abort rebase
  7. abortingRebaseFailedNoOrigHead=Could not abort rebase since ORIG_HEAD is null
  8. advertisementCameBefore=advertisement of {0}^'{}' came before {1}
  9. advertisementOfCameBefore=advertisement of {0}^'{}' came before {1}
  10. amazonS3ActionFailed={0} of ''{1}'' failed: {2} {3}
  11. amazonS3ActionFailedGivingUp={0} of ''{1}'' failed: Giving up after {2} attempts.
  12. ambiguousObjectAbbreviation=Object abbreviation {0} is ambiguous
  13. aNewObjectIdIsRequired=A NewObjectId is required.
  14. anExceptionOccurredWhileTryingToAddTheIdOfHEAD=An exception occurred while trying to add the Id of HEAD
  15. anSSHSessionHasBeenAlreadyCreated=An SSH session has been already created
  16. applyBinaryBaseOidWrong=Cannot apply binary patch; OID for file {0} does not match
  17. applyBinaryOidTooShort=Binary patch for file {0} does not have full IDs
  18. applyBinaryResultOidWrong=Result of binary patch for file {0} has wrong OID.
  19. applyingCommit=Applying {0}
  20. archiveFormatAlreadyAbsent=Archive format already absent: {0}
  21. archiveFormatAlreadyRegistered=Archive format already registered with different implementation: {0}
  22. argumentIsNotAValidCommentString=Invalid comment: {0}
  23. assumeAtomicCreateNewFile=Reading option "core.supportsAtomicFileCreation" failed, fallback to default assuming atomic file creation is supported
  24. atLeastOnePathIsRequired=At least one path is required.
  25. atLeastOnePatternIsRequired=At least one pattern is required.
  26. atLeastTwoFiltersNeeded=At least two filters needed.
  27. atomicPushNotSupported=Atomic push not supported.
  28. atomicRefUpdatesNotSupported=Atomic ref updates not supported
  29. atomicSymRefNotSupported=Atomic symref not supported
  30. authenticationNotSupported=authentication not supported
  31. badBase64InputCharacterAt=Bad Base64 input character at {0} : {1} (decimal)
  32. badEntryDelimiter=Bad entry delimiter
  33. badEntryName=Bad entry name: {0}
  34. badEscape=Bad escape: {0}
  35. badGroupHeader=Bad group header
  36. badIgnorePattern=Cannot parse .gitignore pattern ''{0}''
  37. badIgnorePatternFull=File {0} line {1}: cannot parse pattern ''{2}'': {3}
  38. badObjectType=Bad object type: {0}
  39. badRef=Bad ref: {0}: {1}
  40. badSectionEntry=Bad section entry: {0}
  41. badShallowLine=Bad shallow line: {0}
  42. bareRepositoryNoWorkdirAndIndex=Bare Repository has neither a working tree, nor an index
  43. base85invalidChar=Invalid base-85 character: 0x{0}
  44. base85length=Base-85 encoded data must have a length that is a multiple of 5
  45. base85overflow=Base-85 value overflow, does not fit into 32 bits: 0x{0}
  46. base85tooLong=Extra base-85 encoded data for output size of {0} bytes
  47. base85tooShort=Base-85 data decoded into less than {0} bytes
  48. baseLengthIncorrect=base length incorrect
  49. binaryDeltaBaseLengthMismatch=Binary delta base length does not match, expected {0}, got {1}
  50. binaryDeltaInvalidOffset=Binary delta offset + length too large: {0} + {1}
  51. binaryDeltaInvalidResultLength=Binary delta expected result length is negative
  52. binaryHunkDecodeError=Binary hunk, line {0}: invalid input
  53. binaryHunkInvalidLength=Binary hunk, line {0}: input corrupt; expected length byte, got 0x{1}
  54. binaryHunkLineTooShort=Binary hunk, line {0}: input ended prematurely
  55. binaryHunkMissingNewline=Binary hunk, line {0}: input line not terminated by newline
  56. bitmapMissingObject=Bitmap at {0} is missing {1}.
  57. bitmapsMustBePrepared=Bitmaps must be prepared before they may be written.
  58. blameNotCommittedYet=Not Committed Yet
  59. blockLimitNotMultipleOfBlockSize=blockLimit {0} must be a multiple of blockSize {1}
  60. blockLimitNotPositive=blockLimit must be positive: {0}
  61. blockSizeNotPowerOf2=blockSize must be a power of 2
  62. bothRefTargetsMustNotBeNull=both old and new ref targets must not be null.
  63. branchNameInvalid=Branch name {0} is not allowed
  64. buildingBitmaps=Building bitmaps
  65. cachedPacksPreventsIndexCreation=Using cached packs prevents index creation
  66. cachedPacksPreventsListingObjects=Using cached packs prevents listing objects
  67. cannotAccessLastModifiedForSafeDeletion=Unable to access lastModifiedTime of file {0}, skip deletion since we cannot safely avoid race condition
  68. cannotBeCombined=Cannot be combined.
  69. cannotBeRecursiveWhenTreesAreIncluded=TreeWalk shouldn't be recursive when tree objects are included.
  70. cannotChangeActionOnComment=Cannot change action on comment line in git-rebase-todo file, old action: {0}, new action: {1}.
  71. cannotCheckoutFromUnbornBranch=Cannot check out from unborn branch
  72. cannotCheckoutOursSwitchBranch=Checking out ours/theirs is only possible when checking out index, not when switching branches.
  73. cannotCombineSquashWithNoff=Cannot combine --squash with --no-ff.
  74. cannotCombineTopoSortWithTopoKeepBranchTogetherSort=Cannot combine sorts TOPO and TOPO_KEEP_BRANCH_TOGETHER
  75. cannotCombineTreeFilterWithRevFilter=Cannot combine TreeFilter {0} with RevFilter {1}.
  76. cannotCommitOnARepoWithState=Cannot commit on a repo with state: {0}
  77. cannotCommitWriteTo=Cannot commit write to {0}
  78. cannotConnectPipes=cannot connect pipes
  79. cannotConvertScriptToText=Cannot convert script to text
  80. cannotCreateConfig=cannot create config
  81. cannotCreateDirectory=Cannot create directory {0}
  82. cannotCreateHEAD=cannot create HEAD
  83. cannotCreateIndexfile=Cannot create an index file with name {0}
  84. cannotCreateTempDir=Cannot create a temp dir
  85. cannotDeleteCheckedOutBranch=Branch {0} is checked out and cannot be deleted
  86. cannotDeleteFile=Cannot delete file: {0}
  87. cannotDeleteObjectsPath=Cannot delete {0}/{1}: {2}
  88. cannotDetermineProxyFor=Cannot determine proxy for {0}
  89. cannotDownload=Cannot download {0}
  90. cannotEnterObjectsPath=Cannot enter {0}/objects: {1}
  91. cannotEnterPathFromParent=Cannot enter {0} from {1}: {2}
  92. cannotExecute=cannot execute: {0}
  93. cannotFindMergeBaseUsingFirstParent=Cannot find merge bases using a first-parent walk.
  94. cannotGet=Cannot get {0}
  95. cannotGetObjectsPath=Cannot get {0}/{1}: {2}
  96. cannotListObjectsPath=Cannot ls {0}/{1}: {2}
  97. cannotListPackPath=Cannot ls {0}/pack: {1}
  98. cannotListRefs=cannot list refs
  99. cannotLock=Cannot lock {0}. Ensure that no other process has an open file handle on the lock file {0}.lock, then you may delete the lock file and retry.
  100. cannotLockPackIn=Cannot lock pack in {0}
  101. cannotMatchOnEmptyString=Cannot match on empty string.
  102. cannotMkdirObjectPath=Cannot create directory {0}/{1}: {2}
  103. cannotMoveIndexTo=Cannot move index to {0}
  104. cannotMovePackTo=Cannot move pack to {0}
  105. cannotOpenService=cannot open {0}
  106. cannotParseDate=The date specification "{0}" could not be parsed with the following formats: {1}
  107. cannotParseGitURIish=Cannot parse Git URI-ish
  108. cannotPullOnARepoWithState=Cannot pull into a repository with state: {0}
  109. cannotRead=Cannot read {0}
  110. cannotReadBackDelta=Cannot read delta type {0}
  111. cannotReadBlob=Cannot read blob {0}
  112. cannotReadCommit=Cannot read commit {0}
  113. cannotReadFile=Cannot read file {0}
  114. cannotReadHEAD=cannot read HEAD: {0} {1}
  115. cannotReadIndex=The index file {0} exists but cannot be read
  116. cannotReadObject=Cannot read object
  117. cannotReadObjectsPath=Cannot read {0}/{1}: {2}
  118. cannotReadTree=Cannot read tree {0}
  119. cannotRebaseWithoutCurrentHead=Can not rebase without a current HEAD
  120. cannotSaveConfig=Cannot save config file ''{0}''
  121. cannotSquashFixupWithoutPreviousCommit=Cannot {0} without previous commit.
  122. cannotStoreObjects=cannot store objects
  123. cannotResolveUniquelyAbbrevObjectId=Could not resolve uniquely the abbreviated object ID
  124. cannotUpdateUnbornBranch=Cannot update unborn branch
  125. cannotWriteObjectsPath=Cannot write {0}/{1}: {2}
  126. canOnlyCherryPickCommitsWithOneParent=Cannot cherry-pick commit ''{0}'' because it has {1} parents, only commits with exactly one parent are supported.
  127. canOnlyRevertCommitsWithOneParent=Cannot revert commit ''{0}'' because it has {1} parents, only commits with exactly one parent are supported
  128. commitDoesNotHaveGivenParent=The commit ''{0}'' does not have a parent number {1}.
  129. cantFindObjectInReversePackIndexForTheSpecifiedOffset=Can''t find object in (reverse) pack index for the specified offset {0}
  130. channelMustBeInRange1_255=channel {0} must be in range [1, 255]
  131. characterClassIsNotSupported=The character class {0} is not supported.
  132. checkingOutFiles=Checking out files
  133. checkoutConflictWithFile=Checkout conflict with file: {0}
  134. checkoutConflictWithFiles=Checkout conflict with files: {0}
  135. checkoutUnexpectedResult=Checkout returned unexpected result {0}
  136. classCastNotA=Not a {0}
  137. cloneNonEmptyDirectory=Destination path "{0}" already exists and is not an empty directory
  138. closed=closed
  139. closeLockTokenFailed=Closing LockToken ''{0}'' failed
  140. collisionOn=Collision on {0}
  141. commandClosedStderrButDidntExit=Command {0} closed stderr stream but didn''t exit within timeout {1} seconds
  142. commandRejectedByHook=Rejected by "{0}" hook.\n{1}
  143. commandWasCalledInTheWrongState=Command {0} was called in the wrong state
  144. commitMessageNotSpecified=commit message not specified
  145. commitOnRepoWithoutHEADCurrentlyNotSupported=Commit on repo without HEAD currently not supported
  146. commitAmendOnInitialNotPossible=Amending is not possible on initial commit.
  147. commitsHaveAlreadyBeenMarkedAsStart=Commits have already been marked as walk starts.
  148. compressingObjects=Compressing objects
  149. configSubsectionContainsNewline=config subsection name contains newline
  150. configSubsectionContainsNullByte=config subsection name contains byte 0x00
  151. configValueContainsNullByte=config value contains byte 0x00
  152. configHandleIsStale=config file handle is stale, {0}. retry
  153. configHandleMayBeLocked=config file handle may be locked by other process, {0}. retry
  154. connectionFailed=connection failed
  155. connectionTimeOut=Connection time out: {0}
  156. contextMustBeNonNegative=context must be >= 0
  157. cookieFilePathRelative=git config http.cookieFile contains a relative path, should be absolute: {0}
  158. corruptionDetectedReReadingAt=Corruption detected re-reading at {0}
  159. corruptObjectBadDate=bad date
  160. corruptObjectBadEmail=bad email
  161. corruptObjectBadStream=bad stream
  162. corruptObjectBadTimezone=bad time zone
  163. corruptObjectDuplicateEntryNames=duplicate entry names
  164. corruptObjectGarbageAfterSize=garbage after size
  165. corruptObjectIncorrectLength=incorrect length
  166. corruptObjectIncorrectSorting=incorrectly sorted
  167. corruptObjectInvalidModeChar=invalid mode character
  168. corruptObjectInvalidModeStartsZero=mode starts with '0'
  169. corruptObjectInvalidMode2=invalid mode {0,number,#}
  170. corruptObjectInvalidMode3=invalid mode {0} for {1} ''{2}'' in {3}.
  171. corruptObjectInvalidName=invalid name '%s'
  172. corruptObjectInvalidNameAux=invalid name 'AUX'
  173. corruptObjectInvalidNameCon=invalid name 'CON'
  174. corruptObjectInvalidNameCom=invalid name 'COM%c'
  175. corruptObjectInvalidNameEnd=invalid name ends with '%c'
  176. corruptObjectInvalidNameIgnorableUnicode=invalid name '%s' contains ignorable Unicode characters
  177. corruptObjectInvalidNameInvalidUtf8=invalid name contains byte sequence ''{0}'' which is not a valid UTF-8 character
  178. corruptObjectInvalidNameLpt=invalid name 'LPT%c'
  179. corruptObjectInvalidNameNul=invalid name 'NUL'
  180. corruptObjectInvalidNamePrn=invalid name 'PRN'
  181. corruptObjectInvalidObject=invalid object
  182. corruptObjectInvalidParent=invalid parent
  183. corruptObjectInvalidTree=invalid tree
  184. corruptObjectInvalidType=invalid type
  185. corruptObjectInvalidType2=invalid type {0}
  186. corruptObjectMissingEmail=missing email
  187. corruptObjectNameContainsByte=byte 0x%x not allowed in Windows filename
  188. corruptObjectNameContainsChar=char '%c' not allowed in Windows filename
  189. corruptObjectNameContainsNullByte=name contains byte 0x00
  190. corruptObjectNameContainsSlash=name contains '/'
  191. corruptObjectNameDot=invalid name '.'
  192. corruptObjectNameDotDot=invalid name '..'
  193. corruptObjectNameZeroLength=zero length name
  194. corruptObjectNegativeSize=negative size
  195. corruptObjectNoAuthor=no author
  196. corruptObjectNoCommitter=no committer
  197. corruptObjectNoHeader=no header
  198. corruptObjectNoObjectHeader=no object header
  199. corruptObjectNoTagHeader=no tag header
  200. corruptObjectNotreeHeader=no tree header
  201. corruptObjectNoTypeHeader=no type header
  202. corruptObjectPackfileChecksumIncorrect=Packfile checksum incorrect.
  203. corruptObjectTruncatedInMode=truncated in mode
  204. corruptObjectTruncatedInName=truncated in name
  205. corruptObjectTruncatedInObjectId=truncated in object id
  206. corruptObjectZeroId=entry points to null SHA-1
  207. corruptUseCnt=close() called when useCnt is already zero for {0}
  208. couldNotGetAdvertisedRef=Remote {0} did not advertise Ref for branch {1}. This Ref may not exist in the remote or may be hidden by permission settings.
  209. couldNotGetRepoStatistics=Could not get repository statistics
  210. couldNotFindTabInLine=Could not find tab in line {0}. Tab is the mandatory separator for the Netscape Cookie File Format.
  211. couldNotFindSixTabsInLine=Could not find 6 tabs but only {0} in line '{1}'. 7 tab separated columns per line are mandatory for the Netscape Cookie File Format.
  212. couldNotLockHEAD=Could not lock HEAD
  213. couldNotPersistCookies=Could not persist received cookies in file ''{0}''
  214. couldNotReadCookieFile=Could not read cookie file ''{0}''
  215. couldNotReadIndexInOneGo=Could not read index in one go, only {0} out of {1} read
  216. couldNotReadObjectWhileParsingCommit=Could not read an object while parsing commit {0}
  217. couldNotRewindToUpstreamCommit=Could not rewind to upstream commit
  218. couldNotURLEncodeToUTF8=Could not URL encode to UTF-8
  219. countingObjects=Counting objects
  220. corruptPack=Pack file {0} is corrupt, removing it from pack list
  221. createBranchFailedUnknownReason=Create branch failed for unknown reason
  222. createBranchUnexpectedResult=Create branch returned unexpected result {0}
  223. createNewFileFailed=Could not create new file {0}
  224. createRequiresZeroOldId=Create requires old ID to be zero
  225. credentialPassword=Password
  226. credentialPassphrase=Passphrase
  227. credentialUsername=Username
  228. daemonAlreadyRunning=Daemon already running
  229. daysAgo={0} days ago
  230. deepenNotWithDeepen=Cannot combine deepen with deepen-not
  231. deepenSinceWithDeepen=Cannot combine deepen with deepen-since
  232. deleteBranchUnexpectedResult=Delete branch returned unexpected result {0}
  233. deleteFileFailed=Could not delete file {0}
  234. deletedOrphanInPackDir=Deleted orphaned file {}
  235. deleteRequiresZeroNewId=Delete requires new ID to be zero
  236. deleteTagUnexpectedResult=Delete tag returned unexpected result {0}
  237. deletingNotSupported=Deleting {0} not supported.
  238. destinationIsNotAWildcard=Destination is not a wildcard.
  239. detachedHeadDetected=HEAD is detached
  240. dirCacheDoesNotHaveABackingFile=DirCache does not have a backing file
  241. dirCacheFileIsNotLocked=DirCache {0} not locked
  242. dirCacheIsNotLocked=DirCache is not locked
  243. DIRCChecksumMismatch=DIRC checksum mismatch
  244. DIRCCorruptLength=DIRC variable int {0} invalid after entry for {1}
  245. DIRCCorruptLengthFirst=DIRC variable int {0} invalid in first entry
  246. DIRCExtensionIsTooLargeAt=DIRC extension {0} is too large at {1} bytes.
  247. DIRCExtensionNotSupportedByThisVersion=DIRC extension {0} not supported by this version.
  248. DIRCHasTooManyEntries=DIRC has too many entries.
  249. DIRCUnrecognizedExtendedFlags=Unrecognized extended flags: {0}
  250. downloadCancelled=Download cancelled
  251. downloadCancelledDuringIndexing=Download cancelled during indexing
  252. duplicateAdvertisementsOf=duplicate advertisements of {0}
  253. duplicateRef=Duplicate ref: {0}
  254. duplicateRefAttribute=Duplicate ref attribute: {0}
  255. duplicateRemoteRefUpdateIsIllegal=Duplicate remote ref update is illegal. Affected remote name: {0}
  256. duplicateStagesNotAllowed=Duplicate stages not allowed
  257. eitherGitDirOrWorkTreeRequired=One of setGitDir or setWorkTree must be called.
  258. emptyCommit=No changes
  259. emptyPathNotPermitted=Empty path not permitted.
  260. emptyRef=Empty ref: {0}
  261. encryptionError=Encryption error: {0}
  262. encryptionOnlyPBE=Encryption error: only password-based encryption (PBE) algorithms are supported.
  263. endOfFileInEscape=End of file in escape
  264. entryNotFoundByPath=Entry not found by path: {0}
  265. enumValueNotSupported0=Invalid value: {0}
  266. enumValueNotSupported2=Invalid value: {0}.{1}={2}
  267. enumValueNotSupported3=Invalid value: {0}.{1}.{2}={3}
  268. enumValuesNotAvailable=Enumerated values of type {0} not available
  269. errorInPackedRefs=error in packed-refs
  270. errorInvalidProtocolWantedOldNewRef=error: invalid protocol: wanted 'old new ref'
  271. errorListing=Error listing {0}
  272. errorOccurredDuringUnpackingOnTheRemoteEnd=error occurred during unpacking on the remote end: {0}
  273. errorReadingInfoRefs=error reading info/refs
  274. exceptionCaughtDuringExecutionOfHook=Exception caught during execution of "{0}" hook.
  275. exceptionCaughtDuringExecutionOfAddCommand=Exception caught during execution of add command
  276. exceptionCaughtDuringExecutionOfArchiveCommand=Exception caught during execution of archive command
  277. exceptionCaughtDuringExecutionOfCherryPickCommand=Exception caught during execution of cherry-pick command. {0}
  278. exceptionCaughtDuringExecutionOfCommand=Exception caught during execution of command ''{0}'' in ''{1}'', return code ''{2}'', error message ''{3}''
  279. exceptionCaughtDuringExecutionOfCommitCommand=Exception caught during execution of commit command
  280. exceptionCaughtDuringExecutionOfFetchCommand=Exception caught during execution of fetch command
  281. exceptionCaughtDuringExecutionOfLsRemoteCommand=Exception caught during execution of ls-remote command
  282. exceptionCaughtDuringExecutionOfMergeCommand=Exception caught during execution of merge command. {0}
  283. exceptionCaughtDuringExecutionOfPullCommand=Exception caught during execution of pull command
  284. exceptionCaughtDuringExecutionOfPushCommand=Exception caught during execution of push command
  285. exceptionCaughtDuringExecutionOfResetCommand=Exception caught during execution of reset command. {0}
  286. exceptionCaughtDuringExecutionOfRevertCommand=Exception caught during execution of revert command. {0}
  287. exceptionCaughtDuringExecutionOfRmCommand=Exception caught during execution of rm command
  288. exceptionCaughtDuringExecutionOfTagCommand=Exception caught during execution of tag command
  289. exceptionHookExecutionInterrupted=Execution of "{0}" hook interrupted.
  290. exceptionOccurredDuringAddingOfOptionToALogCommand=Exception occurred during adding of {0} as option to a Log command
  291. exceptionOccurredDuringReadingOfGIT_DIR=Exception occurred during reading of $GIT_DIR/{0}. {1}
  292. exceptionWhileFindingUserHome=Problem determining the user home directory, trying Java user.home
  293. exceptionWhileReadingPack=Exception caught while accessing pack file {0}, the pack file might be corrupt. Caught {1} consecutive errors while trying to read this pack.
  294. expectedACKNAKFoundEOF=Expected ACK/NAK, found EOF
  295. expectedACKNAKGot=Expected ACK/NAK, got: {0}
  296. expectedBooleanStringValue=Expected boolean string value
  297. expectedCharacterEncodingGuesses=Expected {0} character encoding guesses
  298. expectedDirectoryNotSubmodule=Expected submodule ''{0}'' to be a directory
  299. expectedEOFReceived=expected EOF; received ''{0}'' instead
  300. expectedGot=expected ''{0}'', got ''{1}''
  301. expectedLessThanGot=expected less than ''{0}'', got ''{1}''
  302. expectedPktLineWithService=expected pkt-line with ''# service=-'', got ''{0}''
  303. expectedReceivedContentType=expected Content-Type {0}; received Content-Type {1}
  304. expectedReportForRefNotReceived={0}: expected report for ref {1} not received
  305. failedAtomicFileCreation=Atomic file creation failed, number of hard links to file {0} was not 2 but {1}
  306. failedCreateLockFile=Creating lock file {} failed
  307. failedReadHttpsProtocols=Failed to read system property https.protocols, assuming it is not set
  308. failedToConvert=Failed to convert rest: %s
  309. failedToDetermineFilterDefinition=An exception occurred while determining filter definitions
  310. failedUpdatingRefs=failed updating refs
  311. failureDueToOneOfTheFollowing=Failure due to one of the following:
  312. failureUpdatingFETCH_HEAD=Failure updating FETCH_HEAD: {0}
  313. failureUpdatingTrackingRef=Failure updating tracking ref {0}: {1}
  314. fileAlreadyExists=File already exists: {0}
  315. fileCannotBeDeleted=File cannot be deleted: {0}
  316. fileIsTooLarge=File is too large: {0}
  317. fileModeNotSetForPath=FileMode not set for path {0}
  318. filterExecutionFailed=Execution of filter command ''{0}'' on file ''{1}'' failed
  319. filterExecutionFailedRc=Execution of filter command ''{0}'' on file ''{1}'' failed with return code ''{2}'', message on stderr: ''{3}''
  320. filterRequiresCapability=filter requires server to advertise that capability
  321. findingGarbage=Finding garbage
  322. flagIsDisposed={0} is disposed.
  323. flagNotFromThis={0} not from this.
  324. flagsAlreadyCreated={0} flags already created.
  325. funnyRefname=funny refname
  326. gcFailed=Garbage collection failed.
  327. gcTooManyUnpruned=Too many loose, unpruneable objects after garbage collection. Consider adjusting gc.auto or gc.pruneExpire.
  328. headRequiredToStash=HEAD required to stash local changes
  329. hoursAgo={0} hours ago
  330. httpConfigCannotNormalizeURL=Cannot normalize URL path {0}: too many .. segments
  331. httpConfigInvalidURL=Cannot parse URL from subsection http.{0} in git config; ignored.
  332. httpFactoryInUse=Changing the HTTP connection factory after an HTTP connection has already been opened is not allowed.
  333. httpPreAuthTooLate=HTTP Basic preemptive authentication cannot be set once an HTTP connection has already been opened.
  334. httpUserInfoDecodeError=Cannot decode user info from URL {}; ignored.
  335. httpWrongConnectionType=Wrong connection type: expected {0}, got {1}.
  336. hugeIndexesAreNotSupportedByJgitYet=Huge indexes are not supported by jgit, yet
  337. hunkBelongsToAnotherFile=Hunk belongs to another file
  338. hunkDisconnectedFromFile=Hunk disconnected from file
  339. hunkHeaderDoesNotMatchBodyLineCountOf=Hunk header {0} does not match body line count of {1}
  340. illegalArgumentNotA=Not {0}
  341. illegalCombinationOfArguments=The combination of arguments {0} and {1} is not allowed
  342. illegalHookName=Illegal hook name {0}
  343. illegalPackingPhase=Illegal packing phase {0}
  344. incorrectHashFor=Incorrect hash for {0}; computed {1} as a {2} from {3} bytes.
  345. incorrectOBJECT_ID_LENGTH=Incorrect OBJECT_ID_LENGTH.
  346. indexFileCorruptedNegativeBucketCount=Invalid negative bucket count read from pack v2 index file: {0}
  347. indexFileIsTooLargeForJgit=Index file is too large for jgit
  348. indexNumbersNotIncreasing=index numbers not increasing: ''{0}'': min {1}, last max {2}
  349. indexWriteException=Modified index could not be written
  350. initFailedBareRepoDifferentDirs=When initializing a bare repo with directory {0} and separate git-dir {1} specified both folders must point to the same location
  351. initFailedDirIsNoDirectory=Cannot set directory to ''{0}'' which is not a directory
  352. initFailedGitDirIsNoDirectory=Cannot set git-dir to ''{0}'' which is not a directory
  353. initFailedNonBareRepoSameDirs=When initializing a non-bare repo with directory {0} and separate git-dir {1} specified both folders should not point to the same location
  354. inMemoryBufferLimitExceeded=In-memory buffer limit exceeded
  355. inputDidntMatchLength=Input did not match supplied length. {0} bytes are missing.
  356. inputStreamMustSupportMark=InputStream must support mark()
  357. integerValueOutOfRange=Integer value {0}.{1} out of range
  358. internalRevisionError=internal revision error
  359. internalServerError=internal server error
  360. interruptedWriting=Interrupted writing {0}
  361. inTheFuture=in the future
  362. invalidAdvertisementOf=invalid advertisement of {0}
  363. invalidAncestryLength=Invalid ancestry length
  364. invalidBooleanValue=Invalid boolean value: {0}.{1}={2}
  365. invalidChannel=Invalid channel {0}
  366. invalidCommitParentNumber=Invalid commit parent number
  367. invalidDepth=Invalid depth: {0}
  368. invalidEncryption=Invalid encryption
  369. invalidExpandWildcard=ExpandFromSource on a refspec that can have mismatched wildcards does not make sense.
  370. invalidFilter=Invalid filter: {0}
  371. invalidGitdirRef = Invalid .git reference in file ''{0}''
  372. invalidGitModules=Invalid .gitmodules file
  373. invalidGitType=invalid git type: {0}
  374. invalidHeaderFormat=Invalid header from git config http.extraHeader ignored: no colon or empty key in header ''{0}''
  375. invalidHeaderKey=Invalid header from git config http.extraHeader ignored: key contains illegal characters; see RFC 7230: ''{0}''
  376. invalidHeaderValue=Invalid header from git config http.extraHeader ignored: value should be 7bit-ASCII characters only: ''{0}''
  377. invalidHexString=Invalid hex string: {0}
  378. invalidHomeDirectory=Invalid home directory: {0}
  379. invalidHooksPath=Invalid git config core.hooksPath = {0}
  380. invalidId=Invalid id: {0}
  381. invalidId0=Invalid id
  382. invalidIdLength=Invalid id length {0}; should be {1}
  383. invalidIgnoreParamSubmodule=Found invalid ignore param for submodule {0}.
  384. invalidIgnoreRule=Exception caught while parsing ignore rule ''{0}''.
  385. invalidIntegerValue=Invalid integer value: {0}.{1}={2}
  386. invalidKey=Invalid key: {0}
  387. invalidLineInConfigFile=Invalid line in config file
  388. invalidLineInConfigFileWithParam=Invalid line in config file: {0}
  389. invalidModeFor=Invalid mode {0} for {1} {2} in {3}.
  390. invalidModeForPath=Invalid mode {0} for path {1}
  391. invalidNameContainsDotDot=Invalid name (contains ".."): {0}
  392. invalidObject=Invalid {0} {1}: {2}
  393. invalidOldIdSent=invalid old id sent
  394. invalidPacketLineHeader=Invalid packet line header: {0}
  395. invalidPath=Invalid path: {0}
  396. invalidPurgeFactor=Invalid purgeFactor {0}, values have to be in range between 0 and 1
  397. invalidRedirectLocation=Invalid redirect location {0} -> {1}
  398. invalidRefAdvertisementLine=Invalid ref advertisement line: ''{0}''
  399. invalidReflogRevision=Invalid reflog revision: {0}
  400. invalidRefName=Invalid ref name: {0}
  401. invalidReftableBlock=Invalid reftable block
  402. invalidReftableCRC=Invalid reftable CRC-32
  403. invalidReftableFile=Invalid reftable file
  404. invalidRemote=Invalid remote: {0}
  405. invalidRepositoryStateNoHead=Invalid repository --- cannot read HEAD
  406. invalidShallowObject=invalid shallow object {0}, expected commit
  407. invalidStageForPath=Invalid stage {0} for path {1}
  408. invalidSystemProperty=Invalid system property ''{0}'': ''{1}''; using default value {2}
  409. invalidTagOption=Invalid tag option: {0}
  410. invalidTimeout=Invalid timeout: {0}
  411. invalidTimestamp=Invalid timestamp in {0}
  412. invalidTimeUnitValue2=Invalid time unit value: {0}.{1}={2}
  413. invalidTimeUnitValue3=Invalid time unit value: {0}.{1}.{2}={3}
  414. invalidTreeZeroLengthName=Cannot append a tree entry with zero-length name
  415. invalidURL=Invalid URL {0}
  416. invalidWildcards=Invalid wildcards {0}
  417. invalidRefSpec=Invalid refspec {0}
  418. invalidWindowSize=Invalid window size
  419. isAStaticFlagAndHasNorevWalkInstance={0} is a static flag and has no RevWalk instance
  420. JRELacksMD5Implementation=JRE lacks MD5 implementation
  421. kNotInRange=k {0} not in {1} - {2}
  422. largeObjectExceedsByteArray=Object {0} exceeds 2 GiB byte array limit
  423. largeObjectExceedsLimit=Object {0} exceeds {1} limit, actual size is {2}
  424. largeObjectException={0} exceeds size limit
  425. largeObjectOutOfMemory=Out of memory loading {0}
  426. lengthExceedsMaximumArraySize=Length exceeds maximum array size
  427. lfsHookConflict=LFS built-in hook conflicts with existing pre-push hook in repository {0}. Either remove the pre-push hook or disable built-in LFS support.
  428. listingAlternates=Listing alternates
  429. listingPacks=Listing packs
  430. localObjectsIncomplete=Local objects incomplete.
  431. localRefIsMissingObjects=Local ref {0} is missing object(s).
  432. localRepository=local repository
  433. lockAlreadyHeld=Lock on {0} already held
  434. lockCountMustBeGreaterOrEqual1=lockCount must be >= 1
  435. lockError=lock error: {0}
  436. lockFailedRetry=locking {0} failed after {1} retries
  437. lockOnNotClosed=Lock on {0} not closed.
  438. lockOnNotHeld=Lock on {0} not held.
  439. lockStreamClosed=Output to lock on {0} already closed
  440. lockStreamMultiple=Output to lock on {0} already opened
  441. logInconsistentFiletimeDiff={}: inconsistent duration from file timestamps on {}, {}: {} > {}, but diff = {}. Aborting measurement at resolution {}.
  442. logLargerFiletimeDiff={}: inconsistent duration from file timestamps on {}, {}: diff = {} > {} (last good value). Aborting measurement.
  443. logSmallerFiletime={}: got smaller file timestamp on {}, {}: {} < {}. Aborting measurement at resolution {}.
  444. logXDGConfigHomeInvalid=Environment variable XDG_CONFIG_HOME contains an invalid path {}
  445. maxCountMustBeNonNegative=max count must be >= 0
  446. mergeConflictOnNonNoteEntries=Merge conflict on non-note entries: base = {0}, ours = {1}, theirs = {2}
  447. mergeConflictOnNotes=Merge conflict on note {0}. base = {1}, ours = {2}, theirs = {2}
  448. mergeStrategyAlreadyExistsAsDefault=Merge strategy "{0}" already exists as a default strategy
  449. mergeStrategyDoesNotSupportHeads=merge strategy {0} does not support {1} heads to be merged into HEAD
  450. mergeUsingStrategyResultedInDescription=Merge of revisions {0} with base {1} using strategy {2} resulted in: {3}. {4}
  451. mergeRecursiveConflictsWhenMergingCommonAncestors=Multiple common ancestors were found and merging them resulted in a conflict: {0}, {1}
  452. mergeRecursiveTooManyMergeBasesFor = "More than {0} merge bases for:\n a {1}\n b {2} found:\n count {3}"
  453. messageAndTaggerNotAllowedInUnannotatedTags = Unannotated tags cannot have a message or tagger
  454. minutesAgo={0} minutes ago
  455. mismatchOffset=mismatch offset for object {0}
  456. mismatchCRC=mismatch CRC for object {0}
  457. missingAccesskey=Missing accesskey.
  458. missingConfigurationForKey=No value for key {0} found in configuration
  459. missingCookieFile=Configured http.cookieFile ''{0}'' is missing
  460. missingCRC=missing CRC for object {0}
  461. missingDeltaBase=delta base
  462. missingForwardImageInGITBinaryPatch=Missing forward-image in GIT binary patch
  463. missingObject=Missing {0} {1}
  464. missingPrerequisiteCommits=missing prerequisite commits:
  465. missingRequiredParameter=Parameter "{0}" is missing
  466. missingSecretkey=Missing secretkey.
  467. mixedStagesNotAllowed=Mixed stages not allowed
  468. mkDirFailed=Creating directory {0} failed
  469. mkDirsFailed=Creating directories for {0} failed
  470. month=month
  471. months=months
  472. monthsAgo={0} months ago
  473. multipleMergeBasesFor=Multiple merge bases for:\n {0}\n {1} found:\n {2}\n {3}
  474. nameMustNotBeNullOrEmpty=Ref name must not be null or empty.
  475. need2Arguments=Need 2 arguments
  476. newIdMustNotBeNull=New ID must not be null
  477. newlineInQuotesNotAllowed=Newline in quotes not allowed
  478. noApplyInDelete=No apply in delete
  479. noClosingBracket=No closing {0} found for {1} at index {2}.
  480. noCommitsSelectedForShallow=No commits selected for shallow request
  481. noCredentialsProvider=Authentication is required but no CredentialsProvider has been registered
  482. noHEADExistsAndNoExplicitStartingRevisionWasSpecified=No HEAD exists and no explicit starting revision was specified
  483. noHMACsupport=No {0} support: {1}
  484. noMergeBase=No merge base could be determined. Reason={0}. {1}
  485. noMergeHeadSpecified=No merge head specified
  486. nonBareLinkFilesNotSupported=Link files are not supported with nonbare repos
  487. nonCommitToHeads=Cannot point a branch to a non-commit object
  488. noPathAttributesFound=No Attributes found for {0}.
  489. noSuchRef=no such ref
  490. noSuchRefKnown=no such ref: {0}
  491. noSuchSubmodule=no such submodule {0}
  492. notABoolean=Not a boolean: {0}
  493. notABundle=not a bundle
  494. notADIRCFile=Not a DIRC file.
  495. notAGitDirectory=not a git directory
  496. notAPACKFile=Not a PACK file.
  497. notARef=Not a ref: {0}: {1}
  498. notASCIIString=Not ASCII string: {0}
  499. notAuthorized=not authorized
  500. notAValidPack=Not a valid pack {0}
  501. notFound=not found.
  502. nothingToFetch=Nothing to fetch.
  503. nothingToPush=Nothing to push.
  504. notMergedExceptionMessage=Branch was not deleted as it has not been merged yet; use the force option to delete it anyway
  505. noXMLParserAvailable=No XML parser available.
  506. objectAtHasBadZlibStream=Object at {0} in {1} has bad zlib stream
  507. objectIsCorrupt=Object {0} is corrupt: {1}
  508. objectIsCorrupt3={0}: object {1}: {2}
  509. objectIsNotA=Object {0} is not a {1}.
  510. objectNotFound=Object {0} not found.
  511. objectNotFoundIn=Object {0} not found in {1}.
  512. obtainingCommitsForCherryPick=Obtaining commits that need to be cherry-picked
  513. oldIdMustNotBeNull=Expected old ID must not be null
  514. onlyOneFetchSupported=Only one fetch supported
  515. onlyOneOperationCallPerConnectionIsSupported=Only one operation call per connection is supported.
  516. onlyOpenPgpSupportedForSigning=OpenPGP is the only supported signing option with JGit at this time (gpg.format must be set to openpgp).
  517. openFilesMustBeAtLeast1=Open files must be >= 1
  518. openingConnection=Opening connection
  519. operationCanceled=Operation {0} was canceled
  520. outputHasAlreadyBeenStarted=Output has already been started.
  521. overflowedReftableBlock=Overflowed reftable block
  522. packChecksumMismatch=Pack checksum mismatch detected for pack file {0}: .pack has {1} whilst .idx has {2}
  523. packCorruptedWhileWritingToFilesystem=Pack corrupted while writing to filesystem
  524. packedRefsHandleIsStale=packed-refs handle is stale, {0}. retry
  525. packetSizeMustBeAtLeast=packet size {0} must be >= {1}
  526. packetSizeMustBeAtMost=packet size {0} must be <= {1}
  527. packedRefsCorruptionDetected=packed-refs corruption detected: {0}
  528. packfileCorruptionDetected=Packfile corruption detected: {0}
  529. packFileInvalid=Pack file invalid: {0}
  530. packfileIsTruncated=Packfile {0} is truncated.
  531. packfileIsTruncatedNoParam=Packfile is truncated.
  532. packHandleIsStale=Pack file {0} handle is stale, removing it from pack list
  533. packHasUnresolvedDeltas=pack has unresolved deltas
  534. packInaccessible=Failed to access pack file {0}, caught {1} consecutive errors while trying to access this pack.
  535. packingCancelledDuringObjectsWriting=Packing cancelled during objects writing
  536. packObjectCountMismatch=Pack object count mismatch: pack {0} index {1}: {2}
  537. packRefs=Pack refs
  538. packSizeNotSetYet=Pack size not yet set since it has not yet been received
  539. packTooLargeForIndexVersion1=Pack too large for index version 1
  540. packWasDeleted=Pack file {0} was deleted, removing it from pack list
  541. packWriterStatistics=Total {0,number,#0} (delta {1,number,#0}), reused {2,number,#0} (delta {3,number,#0})
  542. panicCantRenameIndexFile=Panic: index file {0} must be renamed to replace {1}; until then repository is corrupt
  543. patchApplyException=Cannot apply: {0}
  544. patchFormatException=Format error: {0}
  545. pathNotConfigured=Submodule path is not configured
  546. peeledLineBeforeRef=Peeled line before ref.
  547. peeledRefIsRequired=Peeled ref is required.
  548. peerDidNotSupplyACompleteObjectGraph=peer did not supply a complete object graph
  549. personIdentEmailNonNull=E-mail address of PersonIdent must not be null.
  550. personIdentNameNonNull=Name of PersonIdent must not be null.
  551. postCommitHookFailed=Execution of post-commit hook failed: {0}.
  552. prefixRemote=remote:
  553. problemWithResolvingPushRefSpecsLocally=Problem with resolving push ref specs locally: {0}
  554. progressMonUploading=Uploading {0}
  555. propertyIsAlreadyNonNull=Property is already non null
  556. pruneLoosePackedObjects=Prune loose objects also found in pack files
  557. pruneLooseUnreferencedObjects=Prune loose, unreferenced objects
  558. pullTaskName=Pull
  559. pushCancelled=push cancelled
  560. pushCertificateInvalidField=Push certificate has missing or invalid value for {0}
  561. pushCertificateInvalidFieldValue=Push certificate has missing or invalid value for {0}: {1}
  562. pushCertificateInvalidHeader=Push certificate has invalid header format
  563. pushCertificateInvalidSignature=Push certificate has invalid signature format
  564. pushIsNotSupportedForBundleTransport=Push is not supported for bundle transport
  565. pushNotPermitted=push not permitted
  566. pushOptionsNotSupported=Push options not supported; received {0}
  567. rawLogMessageDoesNotParseAsLogEntry=Raw log message does not parse as log entry
  568. readConfigFailed=Reading config file ''{0}'' failed
  569. readFileStoreAttributesFailed=Reading FileStore attributes from user config failed
  570. readerIsRequired=Reader is required
  571. readingObjectsFromLocalRepositoryFailed=reading objects from local repository failed: {0}
  572. readLastModifiedFailed=Reading lastModified of {0} failed
  573. readPipeIsNotAllowed=FS.readPipe() isn't allowed for command ''{0}''. Working directory: ''{1}''.
  574. readPipeIsNotAllowedRequiredPermission=FS.readPipe() isn't allowed for command ''{0}''. Working directory: ''{1}''. Required permission: {2}.
  575. readTimedOut=Read timed out after {0} ms
  576. receivePackObjectTooLarge1=Object too large, rejecting the pack. Max object size limit is {0} bytes.
  577. receivePackObjectTooLarge2=Object too large ({0} bytes), rejecting the pack. Max object size limit is {1} bytes.
  578. receivePackInvalidLimit=Illegal limit parameter value {0}
  579. receivePackTooLarge=Pack exceeds the limit of {0} bytes, rejecting the pack
  580. receivingObjects=Receiving objects
  581. redirectBlocked=Redirection blocked: redirect {0} -> {1} not allowed
  582. redirectHttp=URI ''{0}'': following HTTP redirect #{1} {2} -> {3}
  583. redirectLimitExceeded=Redirected more than {0} times; aborted at {1} -> {2}
  584. redirectLocationMissing=Invalid redirect: no redirect location for {0}
  585. redirectsOff=Cannot redirect because http.followRedirects is false (HTTP status {0})
  586. refAlreadyExists=already exists
  587. refAlreadyExists1=Ref {0} already exists
  588. reflogEntryNotFound=Entry {0} not found in reflog for ''{1}''
  589. refNotResolved=Ref {0} cannot be resolved
  590. reftableDirExists=reftable dir exists and is nonempty
  591. reftableRecordsMustIncrease=records must be increasing: last {0}, this {1}
  592. refUpdateReturnCodeWas=RefUpdate return code was: {0}
  593. remoteBranchNotFound=Remote branch ''{0}'' not found in upstream origin
  594. remoteConfigHasNoURIAssociated=Remote config "{0}" has no URIs associated
  595. remoteDoesNotHaveSpec=Remote does not have {0} available for fetch.
  596. remoteDoesNotSupportSmartHTTPPush=remote does not support smart HTTP push
  597. remoteHungUpUnexpectedly=remote hung up unexpectedly
  598. remoteNameCannotBeNull=Remote name cannot be null.
  599. renameBranchFailedAmbiguous=Cannot rename branch {0}; name is ambiguous: {1} or {2}
  600. renameBranchFailedNotABranch=Cannot rename {0}: this is not a branch
  601. renameBranchFailedUnknownReason=Rename failed with unknown reason
  602. renameBranchUnexpectedResult=Unexpected rename result {0}
  603. renameCancelled=Rename detection was cancelled
  604. renameFileFailed=Could not rename file {0} to {1}
  605. renamesAlreadyFound=Renames have already been found.
  606. renamesBreakingModifies=Breaking apart modified file pairs
  607. renamesFindingByContent=Finding renames by content similarity
  608. renamesFindingExact=Finding exact renames
  609. renamesRejoiningModifies=Rejoining modified file pairs
  610. repositoryAlreadyExists=Repository already exists: {0}
  611. repositoryConfigFileInvalid=Repository config file {0} invalid {1}
  612. repositoryIsRequired=repository is required
  613. repositoryNotFound=repository not found: {0}
  614. repositoryState_applyMailbox=Apply mailbox
  615. repositoryState_bare=Bare
  616. repositoryState_bisecting=Bisecting
  617. repositoryState_conflicts=Conflicts
  618. repositoryState_merged=Merged
  619. repositoryState_normal=Normal
  620. repositoryState_rebase=Rebase
  621. repositoryState_rebaseInteractive=Interactive rebase
  622. repositoryState_rebaseOrApplyMailbox=Rebase/Apply mailbox
  623. repositoryState_rebaseWithMerge=Rebase w/merge
  624. requiredHashFunctionNotAvailable=Required hash function {0} not available.
  625. resettingHead=Resetting head to {0}
  626. resolvingDeltas=Resolving deltas
  627. resultLengthIncorrect=result length incorrect
  628. rewinding=Rewinding to commit {0}
  629. s3ActionDeletion=Deletion
  630. s3ActionReading=Reading
  631. s3ActionWriting=Writing
  632. searchForReachableBranches=Finding reachable branches
  633. saveFileStoreAttributesFailed=Saving measured FileStore attributes to user config failed
  634. searchForReuse=Finding sources
  635. searchForReuseTimeout=Search for reuse timed out after {0} seconds
  636. searchForSizes=Getting sizes
  637. secondsAgo={0} seconds ago
  638. selectingCommits=Selecting commits
  639. sequenceTooLargeForDiffAlgorithm=Sequence too large for difference algorithm.
  640. serviceNotEnabledNoName=Service not enabled
  641. serviceNotPermitted={1} not permitted on ''{0}''
  642. sha1CollisionDetected=SHA-1 collision detected on {0}
  643. shallowCommitsAlreadyInitialized=Shallow commits have already been initialized
  644. shallowPacksRequireDepthWalk=Shallow packs require a DepthWalk
  645. shortCompressedStreamAt=Short compressed stream at {0}
  646. shortReadOfBlock=Short read of block.
  647. shortReadOfOptionalDIRCExtensionExpectedAnotherBytes=Short read of optional DIRC extension {0}; expected another {1} bytes within the section.
  648. shortSkipOfBlock=Short skip of block.
  649. signatureVerificationError=Signature verification failed
  650. signatureVerificationUnavailable=No signature verifier registered
  651. signedTagMessageNoLf=A non-empty message of a signed tag must end in LF.
  652. signingServiceUnavailable=Signing service is not available
  653. similarityScoreMustBeWithinBounds=Similarity score must be between 0 and 100.
  654. skipMustBeNonNegative=skip must be >= 0
  655. skipNotAccessiblePath=The path ''{0}'' isn't accessible. Skip it.
  656. smartHTTPPushDisabled=smart HTTP push disabled
  657. sourceDestinationMustMatch=Source/Destination must match.
  658. sourceIsNotAWildcard=Source is not a wildcard.
  659. sourceRefDoesntResolveToAnyObject=Source ref {0} doesn''t resolve to any object.
  660. sourceRefNotSpecifiedForRefspec=Source ref not specified for refspec: {0}
  661. squashCommitNotUpdatingHEAD=Squash commit -- not updating HEAD
  662. sshCommandFailed=Execution of ssh command ''{0}'' failed with error ''{1}''
  663. sshCommandTimeout=Execution of ssh command ''{0}'' timed out after {1} seconds
  664. sslFailureExceptionMessage=Secure connection to {0} could not be established because of SSL problems
  665. sslFailureInfo=A secure connection to {0} could not be established because the server''s certificate could not be validated.
  666. sslFailureCause=SSL reported: {0}
  667. sslFailureTrustExplanation=Do you want to skip SSL verification for this server?
  668. sslTrustAlways=Always skip SSL verification for this server from now on
  669. sslTrustForRepo=Skip SSL verification for git operations for repository {0}
  670. sslTrustNow=Skip SSL verification for this single git operation
  671. sslVerifyCannotSave=Could not save setting for http.sslVerify
  672. staleRevFlagsOn=Stale RevFlags on {0}
  673. startingReadStageWithoutWrittenRequestDataPendingIsNotSupported=Starting read stage without written request data pending is not supported
  674. stashApplyConflict=Applying stashed changes resulted in a conflict
  675. stashApplyFailed=Applying stashed changes did not successfully complete
  676. stashApplyOnUnsafeRepository=Cannot apply stashed commit on a repository with state: {0}
  677. stashApplyWithoutHead=Cannot apply stashed commit in an empty repository or onto an unborn branch
  678. stashCommitIncorrectNumberOfParents=Stashed commit ''{0}'' does have {1} parent commits instead of 2 or 3.
  679. stashDropDeleteRefFailed=Deleting stash reference failed with result: {0}
  680. stashDropFailed=Dropping stashed commit failed
  681. stashDropMissingReflog=Stash reflog does not contain entry ''{0}''
  682. stashDropNotSupported=Dropping stash not supported on this ref backend
  683. stashFailed=Stashing local changes did not successfully complete
  684. stashResolveFailed=Reference ''{0}'' does not resolve to stashed commit
  685. statelessRPCRequiresOptionToBeEnabled=stateless RPC requires {0} to be enabled
  686. storePushCertMultipleRefs=Store push certificate for {0} refs
  687. storePushCertOneRef=Store push certificate for {0}
  688. storePushCertReflog=Store push certificate
  689. submoduleExists=Submodule ''{0}'' already exists in the index
  690. submoduleNameInvalid=Invalid submodule name ''{0}''
  691. submoduleParentRemoteUrlInvalid=Cannot remove segment from remote url ''{0}''
  692. submodulePathInvalid=Invalid submodule path ''{0}''
  693. submoduleUrlInvalid=Invalid submodule URL ''{0}''
  694. supportOnlyPackIndexVersion2=Only support index version 2
  695. systemConfigFileInvalid=System wide config file {0} is invalid {1}
  696. tagAlreadyExists=tag ''{0}'' already exists
  697. tagNameInvalid=tag name {0} is invalid
  698. tagOnRepoWithoutHEADCurrentlyNotSupported=Tag on repository without HEAD currently not supported
  699. theFactoryMustNotBeNull=The factory must not be null
  700. threadInterruptedWhileRunning="Current thread interrupted while running {0}"
  701. timeIsUncertain=Time is uncertain
  702. timerAlreadyTerminated=Timer already terminated
  703. timeoutMeasureFsTimestampResolution=measuring filesystem timestamp resolution for ''{0}'' timed out, fall back to resolution of 2 seconds
  704. tooManyCommands=Commands size exceeds limit defined in receive.maxCommandBytes
  705. tooManyFilters=Too many "filter" lines in request
  706. tooManyIncludeRecursions=Too many recursions; circular includes in config file(s)?
  707. topologicalSortRequired=Topological sort required.
  708. transactionAborted=transaction aborted
  709. transportExceptionBadRef=Empty ref: {0}: {1}
  710. transportExceptionEmptyRef=Empty ref: {0}
  711. transportExceptionInvalid=Invalid {0} {1}:{2}
  712. transportExceptionMissingAssumed=Missing assumed {0}
  713. transportExceptionReadRef=read {0}
  714. transportNeedsRepository=Transport needs repository
  715. transportProvidedRefWithNoObjectId=Transport provided ref {0} with no object id
  716. transportProtoBundleFile=Git Bundle File
  717. transportProtoFTP=FTP
  718. transportProtoGitAnon=Anonymous Git
  719. transportProtoHTTP=HTTP
  720. transportProtoLocal=Local Git Repository
  721. transportProtoSFTP=SFTP
  722. transportProtoSSH=SSH
  723. transportProtoTest=Test
  724. treeEntryAlreadyExists=Tree entry "{0}" already exists.
  725. treeFilterMarkerTooManyFilters=Too many markTreeFilters passed, maximum number is {0} (passed {1})
  726. treeWalkMustHaveExactlyTwoTrees=TreeWalk should have exactly two trees.
  727. truncatedHunkLinesMissingForAncestor=Truncated hunk, at least {0} lines missing for ancestor {1}
  728. truncatedHunkNewLinesMissing=Truncated hunk, at least {0} new lines is missing
  729. truncatedHunkOldLinesMissing=Truncated hunk, at least {0} old lines is missing
  730. tSizeMustBeGreaterOrEqual1=tSize must be >= 1
  731. unableToCheckConnectivity=Unable to check connectivity.
  732. unableToCreateNewObject=Unable to create new object: {0}
  733. unableToReadPackfile=Unable to read packfile {0}
  734. unableToRemovePath=Unable to remove path ''{0}''
  735. unableToWrite=Unable to write {0}
  736. unableToSignCommitNoSecretKey=Unable to sign commit. Signing key not available.
  737. unauthorized=Unauthorized
  738. unencodeableFile=Unencodable file: {0}
  739. unexpectedCompareResult=Unexpected metadata comparison result: {0}
  740. unexpectedEndOfConfigFile=Unexpected end of config file
  741. unexpectedEndOfInput=Unexpected end of input
  742. unexpectedEofInPack=Unexpected EOF in partially created pack
  743. unexpectedHunkTrailer=Unexpected hunk trailer
  744. unexpectedOddResult=odd: {0} + {1} - {2}
  745. unexpectedPacketLine=unexpected {0}
  746. unexpectedRefReport={0}: unexpected ref report: {1}
  747. unexpectedReportLine=unexpected report line: {0}
  748. unexpectedReportLine2={0} unexpected report line: {1}
  749. unexpectedSubmoduleStatus=Unexpected submodule status: ''{0}''
  750. unknownOrUnsupportedCommand=Unknown or unsupported command "{0}", only "{1}" is allowed.
  751. unknownDIRCVersion=Unknown DIRC version {0}
  752. unknownHost=unknown host
  753. unknownObject=unknown object
  754. unknownObjectInIndex=unknown object {0} found in index but not in pack file
  755. unknownObjectType=Unknown object type {0}.
  756. unknownObjectType2=unknown
  757. unknownRefStorageFormat=Unknown ref storage format "{0}"
  758. unknownRepositoryFormat=Unknown repository format
  759. unknownRepositoryFormat2=Unknown repository format "{0}"; expected "0".
  760. unknownTransportCommand=unknown command {0}
  761. unknownZlibError=Unknown zlib error.
  762. unlockLockFileFailed=Unlocking LockFile ''{0}'' failed
  763. unmergedPath=Unmerged path: {0}
  764. unmergedPaths=Repository contains unmerged paths
  765. unpackException=Exception while parsing pack stream
  766. unreadablePackIndex=Unreadable pack index: {0}
  767. unrecognizedPackExtension=Unrecognized pack extension: {0}
  768. unrecognizedRef=Unrecognized ref: {0}
  769. unsetMark=Mark not set
  770. unsupportedAlternates=Alternates not supported
  771. unsupportedArchiveFormat=Unknown archive format ''{0}''
  772. unsupportedCommand0=unsupported command 0
  773. unsupportedEncryptionAlgorithm=Unsupported encryption algorithm: {0}
  774. unsupportedEncryptionVersion=Unsupported encryption version: {0}
  775. unsupportedGC=Unsupported garbage collector for repository type: {0}
  776. unsupportedMark=Mark not supported
  777. unsupportedOperationNotAddAtEnd=Not add-at-end: {0}
  778. unsupportedPackIndexVersion=Unsupported pack index version {0}
  779. unsupportedPackVersion=Unsupported pack version {0}.
  780. unsupportedReftableVersion=Unsupported reftable version {0}.
  781. unsupportedRepositoryDescription=Repository description not supported
  782. updateRequiresOldIdAndNewId=Update requires both old ID and new ID to be nonzero
  783. updatingHeadFailed=Updating HEAD failed
  784. updatingReferences=Updating references
  785. updatingRefFailed=Updating the ref {0} to {1} failed. ReturnCode from RefUpdate.update() was {2}
  786. upstreamBranchName=branch ''{0}'' of {1}
  787. uriNotConfigured=Submodule URI not configured
  788. uriNotFound={0} not found
  789. uriNotFoundWithMessage={0} not found: {1}
  790. URINotSupported=URI not supported: {0}
  791. userConfigInvalid=Git config in the user's home directory {0} is invalid {1}
  792. validatingGitModules=Validating .gitmodules files
  793. verifySignatureBad=BAD signature from "{0}"
  794. verifySignatureExpired=Expired signature from "{0}"
  795. verifySignatureGood=Good signature from "{0}"
  796. verifySignatureIssuer=issuer "{0}"
  797. verifySignatureKey=using key {0}
  798. verifySignatureMade=Signature made {0}
  799. verifySignatureTrust=[{0}]
  800. walkFailure=Walk failure.
  801. wantNoSpaceWithCapabilities=No space between oid and first capability in first want line
  802. wantNotValid=want {0} not valid
  803. weeksAgo={0} weeks ago
  804. windowSizeMustBeLesserThanLimit=Window size must be < limit
  805. windowSizeMustBePowerOf2=Window size must be power of 2
  806. writerAlreadyInitialized=Writer already initialized
  807. writeTimedOut=Write timed out after {0} ms
  808. writingNotPermitted=Writing not permitted
  809. writingNotSupported=Writing {0} not supported.
  810. writingObjects=Writing objects
  811. wrongDecompressedLength=wrong decompressed length
  812. wrongRepositoryState=Wrong Repository State: {0}
  813. year=year
  814. years=years
  815. years0MonthsAgo={0} {1} ago
  816. yearsAgo={0} years ago
  817. yearsMonthsAgo={0} {1}, {2} {3} ago