aboutsummaryrefslogtreecommitdiffstats
path: root/org.eclipse.jgit.test/tst
Commit message (Collapse)AuthorAgeFilesLines
* Record the estimated size of the pack files.Thirumala Reddy Mutchukota2017-01-262-0/+385
| | | | | | | | | | | | | | | | | | | | | | | The Compacter and Garbage Collector will record the estimated size of the newly going to be created compact, gc or garbage packs. This information can be used by the clients to better make a call on how to actually store the pack based on the approximated expected size. Added a new protected method DfsObjDatabase.newPack(PackSource packSource, long estimatedPackSize), so that the clients can override this method to make use of the estimatedPackSize while creating a new PackDescription object. The default implementation of this method is equivalent to newPack(packSource).setEstimatedPackSize(estimatedPackSize). I didn't make it abstract because that would force all the existing sub classes of DfsObjDatabase to implement this method. Due to this default implementation, the estimatedPackSize is added to DfsPackDescription using a setter instead of a constructor parameter (even though constructor parameter would be a better choice as this value is set only during the object creation). Change-Id: Iade1122633ea774c2e842178a6a6cbb4a57b598b Signed-off-by: Thirumala Reddy Mutchukota <thirumala@google.com>
* gc: loosen unreferenced objectsDavid Turner2017-01-241-4/+19
| | | | | | | | | | | | | | | | | An unreferenced object might appear in a pack. This could only happen because it was previously referenced, and then later that reference was removed. When we gc, we copy the referenced objects into a new pack, and delete the old pack. This would remove the unreferenced object. Now we first create a loose object from any unreferenced object in the doomed pack. This kicks off the two-week grace period for that object, after which it will be collected if it's not referenced. This matches the behavior of regular git. Change-Id: I59539aca1d0d83622c41aa9bfbdd72fa868ee9fb Signed-off-by: David Turner <dturner@twosigma.com> Signed-off-by: Jonathan Nieder <jrn@google.com>
* gc: Add options to preserve and prune old pack filesJames Melvin2017-01-191-1/+42
| | | | | | | | | | | | | | | | | | | The new --preserve-oldpacks option moves old pack files into the preserved subdirectory instead of deleting them after repacking. The new --prune-preserved option prunes old pack files from the preserved subdirectory after repacking, but before potentially moving the latest old packfiles to this subdirectory. These options are designed to prevent stale file handle exceptions during git operations which can happen on users of NFS repos when repacking is done on them. The strategy is to preserve old pack files around until the next repack with the hopes that they will become unreferenced by then and not cause any exceptions to running processes when they are finally deleted (pruned). Change-Id: If3f729f0d9ce920ee2c3e6acdde46f2068be61d2 Signed-off-by: James Melvin <jmelvin@codeaurora.org>
* Normalizer creating a valid branch name from a stringWim Jongman2017-01-181-0/+82
| | | | | | | | | | | Generic normalization method for a possible invalid branch name. The method compresses dividers between spaces, then replaces spaces and non word characters with underscores. This method is needed in preparation for subsequent EGit changes. Bug: 509878 Change-Id: Ic0d12f098f90f912a45bcc5693d6accf751d4e58 Signed-off-by: Wim Jongman <wim.jongman@remainsoftware.com>
* Merge "Fix StashApplyCommand for stashes containing untracked changes."Christian Halstrick2017-01-161-0/+17
|\
| * Fix StashApplyCommand for stashes containing untracked changes.Thomas Wolf2017-01-151-0/+17
| | | | | | | | | | | | | | | | | | | | | | If there are untracked changes, apply only the untracked tree after a successful merge. The merge tree from merging untracked with HEAD would also contain files already reset before (changes in tracked files) and try to reset those again,leading to false checkout conflicts. Bug: 505804 Change-Id: Iaced4d277623334d11e3d1cca5969590d7c5093e Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* | Fix possible InvalidObjectIdException in ObjectDirectoryMarc Strapetz2017-01-151-0/+44
|/ | | | | | | | | | ObjectDirectory.getShallowCommits should throw an IOException instead of an InvalidArgumentException if invalid SHAs are present in .git/shallow (as this file is usually edited by a human). Change-Id: Ia3a39d38f7aec4282109c7698438f0795fbec905 Signed-off-by: Marc Strapetz <marc.strapetz@syntevo.com> Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* Pack refs/tags/ with refs/heads/Shawn Pearce2017-01-031-9/+5
| | | | | | | | | | | | | | | | | | | | | | This fixes a nasty performance issue for repositories that have many objects referenced through refs/tags/, but not in refs/heads/. Situations like this can arise when a project has made releases like refs/tags/v1.0, and then decides to orphan history and start over for version 2. The v1.0 objects are not reachable from master anymore, but are still live due to the v1.0 tag. When tags are packed in the GC_OTHER pack, bitmaps are not able to cover the repository's contents. This may cause very slow counting times during git clone, as the server must enumerate the ancient history under refs/tags/ to respond to the client. Clients by default always ask for all tags when asking for all heads during clone. This has been true since git-core commit 8434c2f1afedb (Apr 27 2008), when clone was converted to a builtin. Including tags in the main GC pack should still allow servers to benefit from the fast full pack reuse path when serving a clone to a client. Change-Id: I22e29517b5bc6fa3d6b19a19f13bef0c68afdca3
* [findBugs] Fix potential NPE in ObjectDirectoryTestMatthias Sohn2016-12-291-1/+1
| | | | Change-Id: I0307d1e9bbc0bfc8172eed10f8e93788d6e2c8b4 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* [findBugs] Fix potential NPE in GcPackRefsTestMatthias Sohn2016-12-291-1/+2
| | | | Change-Id: I273c06b9b2ce36c8232803cb7f02d7f846ed49e5 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* [findBugs] Fix potential NPE in DirCacheCheckoutTestMatthias Sohn2016-12-291-1/+2
| | | | Change-Id: I842cbdd14bf56cb2bd599255fe90a5a3aea0d304 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Fix keep pack filenameJames Melvin2016-12-271-1/+4
| | | | | | | | | Previously it was looking for a keep file with the name of a pack file (extenstion included) appended with a '.keep'. However, the keep file name should be the pack file name with a '.keep' extension Change-Id: I9dc4c7c393ae20aefa0b9507df8df83610ce4d42 Signed-off-by: James Melvin <jmelvin@codeaurora.org>
* Fix FileSnapshot.isModifiedChristian Halstrick2016-12-132-17/+103
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | FileSnapshot.isModified may have reported a file to be clean although it was actually dirty. Imagine you have a FileSnapshot on file f. lastmodified and lastread are both t0. Now time is t1 and you 1) modify the file 2) update the FileSnapshot of the file (lastModified=t1, lastRead=t1) 3) modify the file again 4) wait 3 seconds 5) ask the Filesnapshot whether the file is dirty or not. It erroneously answered it's clean. Any file which has been modified longer than 2.5 seconds ago was reported to be clean. As the test shows that's not always correct. The real-world problem fixed by this change is the following: * A gerrit server using JGit to serve git repositories is processing fetch requests while simultaneously a native git garbage collection runs on the repo. * At time t1 native git writes temporary files in the pack folder setting the mtime of the pack folder to t1. * A fetch request causes JGit to search for new packfiles and JGit remembers this scan in a Filesnapshot on the packs folder. Since the gc is not finished JGit doesn't see any new packfiles. * The fetch is processed and the gc ends while the filesystem timer is still t1. GC writes a new packfile and deletes the old packfile. * 3 seconds later another request arrives. JGit does not yet know about the new packfile but is also not rescanning the pack folder because it cached that the last scan happened at time t1 and pack folder's mtime is also t1. Now JGit will not be able to resolve any object contained in this new pack. This behavior may be persistent if objects referenced by the ref/meta/config branch are affected so gerrit can't read permissions stored in the refs/meta/config branch anymore and will not allow any pushes anymore. The pack folder will not change its mtime and therefore no rescan will take place. Change-Id: I3efd0ccffeb97b01207dc3e7a6b85c6b06928fad Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Fix merge-base calculationChristian Halstrick2016-11-281-1/+26
| | | | | | | | | | | | | | | | | | | | Fix JGits merge-base calculation in case of inconsistent commit times. JGit was potentially failing to compute correct merge-bases when the commit times where inconsistent (a parent commit was younger than a child commit). The code in MergeBaseGenerator was aware of the fact that sometimes the discovery of a merge base x can occur after the parents of x have been seen (see comment in #carryOntoOne()). But in the light of inconsistent commit times it was possible that these parents of a merge-base have already been returned as a merge-base. This commit fixes the bug by buffering all commits generated by MergeBaseGenerator. It is expected that this buffer will be small because the number of merge-bases will be small. Additionally a new flag is used to mark the ancestors of merge-bases. This allows to filter out the unwanted commits. Bug: 507584 Change-Id: I9cc140b784c3231b972bd2c3de61a789365237ab
* Deprecate SafeBufferedOutputStreamShawn Pearce2016-11-143-21/+13
| | | | | | | | | | | | | | | | | | | | | Java 8 fixed the silent flush during close issue by FilterOutputStream (base class of BufferedOutputStream) using try-with-resources to close the stream, getting a behavior matching what JGit's SafeBufferedOutputStream was doing: try { flush(); } finally { out.close(); } With Java 8 as the minimum required version to run JGit it is no longer necessary to override close() or have this class. Deprecate the class, and use the JRE's version of close. Change-Id: Ic0584c140010278dbe4062df2e71be5df9a797b3
* Organize importsDavid Pursehouse2016-11-1424-41/+27
| | | | | Change-Id: I7c545d06b1bced678c020fab9af1382bc4416b6e Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* Add {get,set}GitwebDescription to RepositoryShawn Pearce2016-11-141-0/+86
| | | | | | | | | | | | | | | | This method pair allows the caller to read and modify the description file that is traditionally used by gitweb and cgit when rendering a repository on the web. Gerrit Code Review has offered this feature for years as part of its GitRepositoryManager interface, but its fundamentally a feature of JGit and its Repository abstraction. git-core typically initializes a repository with a default value inside the description file. During getDescription() this string is converted to null as it is never a useful description. Change-Id: I0a457026c74e9c73ea27e6f070d5fbaca3439be5
* Check that DfsBlockCache#blockSize is a power of 2Philipp Marx2016-11-111-0/+88
| | | | | | | | | | In case a value is used which isn’t a power of 2 there will be a high chance of java.lang.ArrayIndexOutBoundsException and org.eclipse.jgit.errors.CorruptObjectException due to a mismatching assumption for the DfsBlockCache#blockSizeShift parameter. Change-Id: Ib348b3704edf10b5f93a3ffab4fa6f09cbbae231 Signed-off-by: Philipp Marx <smigfu@googlemail.com>
* Fix loop in auto gcMatthias Sohn2016-11-073-2/+142
| | | | | | | | | | * GC.tooManyLooseObjects() always responded true since the loop missed to advance the iterator so it always incremented until the threshold was exceeded. * Also fix loop exit criterion which was off by 1. * Add some tests. Change-Id: I70976dfaa026efbcf3c46bd45941f37277a18e04 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Make streamFileThreshold configurableKevin Corcoran2016-10-241-0/+21
| | | | | | | | | | | | | Previously, the streamFileThreshold, the threshold at which a file would be streamed rather than loaded entirely into memory, was only configurable on a global basis. This commit makes this threshold configurable on a per-loader basis. Bug: 490404 Change-Id: I492c18c3155dbf56eedda9044a61d76120fd75f9 Signed-off-by: Kevin Corcoran <kevin.corcoran@puppetlabs.com> Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* TreeFormatter: disallow empty filenames in treesDavid Turner2016-10-192-1/+18
| | | | | | | | | Git barfs on these (and they don't make any sense), so we certainly shouldn't write them. Change-Id: I3faf8554a05f0fd147be2e63fbe55987d3f88099 Signed-off-by: David Turner <dturner@twosigma.com> Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* DiffCommandTest: Don't call toString on String instancesDavid Pursehouse2016-10-191-5/+5
| | | | | Change-Id: Ib308b3498593d595b3d8741a9b2d241bbc7441c3 Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* FileNameMatcherTest: Use Character.valueOf rather than new CharacterDavid Pursehouse2016-10-191-1/+1
| | | | | Change-Id: I9d6e20a258d34ae1d2700fbe8e6c6e3b0ba94424 Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* Use valueOf rather than constructor for Integer and BooleanDavid Pursehouse2016-10-181-1/+1
| | | | | Change-Id: I1c65b2e40ba6ec5860903b11b4631e014f3dc5ce Signed-off-by: David Pursehouse <david.pursehouse@gmail.com>
* Merge branch 'stable-4.5'Matthias Sohn2016-10-141-0/+21
|\ | | | | | | | | | | | | | | | | | | | | | | * stable-4.5: Unconditionally close repositories in RepositoryCache.clear() Fix eviction of repositories with negative usage count Adapt to parameter removed from RepositoryCache.unregisterAndCloseRepository(). Change-Id: I7087667056ced401a3b3a027977f2715cd77a1c5 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
| * Fix eviction of repositories with negative usage countHugo Arès2016-10-121-0/+21
| | | | | | | | | | | | | | | | | | | | If the repository close method was called twice (or more) for one open, the usage count became negative and the repository was never be evicted from the cache because the method checking if repository is expired was not considering negative usage count. Change-Id: I18a80c415c54c37d1b9def2b311ff2d0afa455ca Signed-off-by: Hugo Arès <hugo.ares@ericsson.com>
* | Fix symlink content comparison on MacOS in tree walkThomas Wolf2016-10-111-0/+234
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Symlinks on MacOS are written as UTF-8 NFD, but readSymbolicLink().toString() converts to NFC with potentially fewer bytes. May occur in particular if the link target has non-ASCII characters for which the NFC and NFD encodings differ. This may lead to an EOFException: Short read of block. This causes all kinds of weird effects in EGit, ranging from failing rebases (which report the exception to the user) to EGit decorations in the navigator silently disappearing (and never coming back). * Rename readContentAsNormalizedString() to readSymlinkTarget() as it's called only for symlinks. Also make it protected. * Fix by allowing the read to succeed even if less than the expected number of bytes are returned by the entry's input stream. * Override in FileTreeIterator to use fs.readSymlink() directly. Includes a new MacOS-only test. Change-Id: I264c5972d67b1cbb1ed690580f5706e671b9affd Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | Fix CheckoutCommand to return updated files even on NONDELETED statusChristian Halstrick2016-09-271-0/+33
| | | | | | | | | | | | | | | | | | | | | | CheckoutCommand was not returning updated and removed files in case of an overall status of NONDELETED. That's status which occurs especially on the Windows platform when Checkout wanted to delete files but the filesystem doesn't allow this. The situation is more seldom on linux/mac because open filehandles don't stop a deletion attempt and checkout succeeds more often. Change-Id: I4828008e58c09bd8f9edaf0f7eda0a79c629fb57
* | Merge branch 'stable-4.5'Matthias Sohn2016-09-241-0/+146
|\| | | | | | | | | | | | | | | * stable-4.5: Fix carrying over flags during a RevWalk Change-Id: Ibf4573c5664271dfa7a6ecc3ede6eaad749f89d8 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
| * Fix carrying over flags during a RevWalkChristian Halstrick2016-09-231-0/+146
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There was a bug when carrying over flags from a merge commit to its non-first parents. The first parent of a merge commit was handled differently and correct but the non-first parents are handled by a recursive algorithm. Flags should be copied from the root merge commit to parent-2, to grandparent-2, ... up to the limit of STACK_DEPTH==500 parents-levels. But the recursive algorithm was always copying only to the direct parents of the merge commit and not the grand*-parents. This seems to be no problem when commits are handled in a strict date order because then copying only one level is no problem if children are handled before parents. But when commits are not seperated anymore by distinctive correct dates (e.g. because all commits have the same date) then it may happen that a merge-parent is handled before the merge commit and when dealing later with the merge commit one has to copy flags down to more than one level Bug: 501211 Change-Id: I2d79a7cf1e3bce21a490905ccd9d5e502d7b8421
* | Add built-in LFS smudge filter for local caseChristian Halstrick2016-09-202-28/+102
| | | | | | | | | | | | | | | | | | | | | | | | Adds a JGit built-in implementation of the "git lfs smudge" filter. This filter should do the same as the one described in [1] besides that it only supports the local case when the lfs objects are already present in the media directory. Remote cases where download of LFS objects from an LFS server is needed will be done in a later commit. [1] https://github.com/github/git-lfs/blob/master/docs/man/git-lfs-smudge.1.ronn Change-Id: I8ff661d4edd3667ef7f86f3b4fa33e568eb4c8f4
* | Add built-in LFS clean filterChristian Halstrick2016-09-201-2/+78
| | | | | | | | | | | | | | | | | | | | | | | | Adds a JGit built-in implementation of the "git lfs clean" filter. This filter should do the same as the one described in [1]. But since this filter is written in Java and can be called by JGit without forking new processes it should be much faster [1] https://github.com/github/git-lfs/blob/master/docs/man/git-lfs-clean.1.ronn Change-Id: If60e387e97870245b4bd765eda6717eb84cffb1d
* | Add support for built-in smudge filtersChristian Halstrick2016-09-201-0/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | JGit supports smudge filters defined in repository configuration. The filters are implemented as external programs filtering content by accepting the original content (as seen in git's object database) on stdin and which emit the filtered content on stdout. This content is then written to the file in the working tree. To run such a filter JGit has to start an external process and pump data into/from this process. This commit adds support for built-in smudge filters which are implemented in Java and which are executed by jgit's main thread. When a filter is defined in the configuration as "jgit://builtin/<filterDriverName>/smudge" then JGit will lookup in a static map whether a builtin filter is registered under this name. If found such a filter is called to do the filtering. The functionality in this commit requires that a program using JGit explicitly calls the JGit API to register built-in implementations for specific smudge filters. In follow-up commits configuration parameters will be added which trigger such registrations. Change-Id: Ia743aa0dbed795e71e5792f35ae55660e0eb3c24
* | Add support for built-in clean filtersChristian Halstrick2016-09-201-0/+157
|/ | | | | | | | | | | | | | | | | | | | | | | JGit supports clean filters defined in repository configuration. The filters are implemented as external programs filtering content by accepting the original content (as seen in the working tree) on stdin and which emit the filtered content on stdout. To run such a filter JGit has to start an external process and pump data into/from this process. This commit adds support for clean filters which are implemented in Java and which are executed by jgit's main thread. When a filter is defined in the configuration as "jgit://builtin/<filterDriverName>/clean" then JGit will lookup in a static map whether a filter is registered under this name. If found such a filter is called to do the filtering. The functionality in this commit requires that a program using JGit explicitly calls the JGit API to register built-in implementations for specific clean filters. In follow-up commits configuration parameters will be added which trigger such registrations. Other commits will add implementations for lfs filters. Change-Id: I0344d3c54801c9a46e5a606c5df17e5f2e17b2be
* Handle all values of branch.[name].rebaseThomas Wolf2016-09-152-37/+58
| | | | | | | | | | | | | | | | | BranchConfig treated this config property as a boolean, but git also allows the values "preserve" and "interactive". Config property pull.rebase also allows the same values. Replace private enum PullCommand.PullRebaseMode by new public enum BranchConfig.BranchRebaseMode and adapt all uses. Add a new setter to PullCommand. Note: PullCommand will treat "interactive" like "true", i.e., as a non-interactive rebase. Not sure how "interactive" should be handled. At least it won't balk on it. Bug: 499482 Change-Id: I7309360f5662b2c2efa1bd8ea6f112c63cf064af Signed-off-by: Thomas Wolf <thomas.wolf@paranor.ch>
* Ignore trailing spaces in directory rule patternsAndrey Loskutov2016-09-143-1/+43
| | | | | | Bug: 500967 Change-Id: I7fabc2654af97011c62f46d5c30ee992341e45e2 Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
* Add support for post-commit hooksMartin Goellnitz2016-09-131-0/+62
| | | | | Change-Id: I6691b454404dd4db3c690ecfc7515de765bc2ef7 Signed-off-by: Martin Goellnitz <m.goellnitz@outlook.com> Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Don't log error if system git config does not existMatthias Sohn2016-09-051-0/+13
| | | | | | | | | | - enhance FS.readPipe to throw an exception if the external command fails to enable the caller to handle the command failure - reduce log level to warning if system git config does not exist - improve log message Bug: 476639 Change-Id: I94ae3caec22150dde81f1ea8e1e665df55290d42 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Rename FSJava7Test to FSTestMatthias Sohn2016-09-031-1/+1
| | | | | | | Since 4.0 JGit does no longer support Java versions older than Java 7 so there is no need anymore to mention Java 7 in the class name. Change-Id: Ic46c9d89a7e919ae4a69487fa06de0478d2b21f0 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* ReceivePack: refactor push option parsingShawn Pearce2016-08-261-10/+8
| | | | | | | | | | | | | Refactor all of the push option support code to allocate the list immediately before parsing the options section off the stream. Move option support down to ReceivePack instead of BaseReceivePack. Push options are specific to the ReceivePack protocol and are not likely to appear in the 4 year old subscription proposal. These changes are OK before JGit 4.5 ships as no consumer should be relying on these new APIs. Change-Id: Ib07d18c877628aba07da07cd91875f918d509c49
* Fix push option initalization on HTTPStefan Beller2016-08-261-1/+1
| | | | | | | | | | | Initialize pushOptions when we decide to use them, instead of when we advertise them. In the case of HTTP the advertisement is in a different network request, hence in a different instance of the BaseReceivePack. Change-Id: I094c60942e04de82cb6d8433c9cd43a46ffae332 Signed-off-by: Stefan Beller <sbeller@google.com>
* Clarify the semantics of DfsRefDatabase#compareAndPutMasaya Suzuki2016-08-251-0/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | DfsRefDatabase#compareAndPut had a vague semantics for reference matching. Because of this, an operation to make a symbolic reference had been broken for some DFS implementations even if they followed the contract of compareAndPut. The clarified semantics requires the implementations to satisfy the followings: * Matching references should be both symbolic references or both object ID references. * If both are symbolic references, both should have the same target name. * If both are object ID references, both should have the same object ID. This semantics is defined based on https://git.eclipse.org/r/#/c/77416/. Before this commit, DfsRefDatabase couldn't see the target of symbolic references. InMemoryRepository is changed to comply with the new semantics. This semantics change can affect the existing DFS implementations that only checks object IDs. This commit adds two tests that the previous InMemoryRepository couldn't pass. Change-Id: I6c6b5d3cc8241a81f4a37782381c88e8a59fdf15 Signed-off-by: Masaya Suzuki <masayasuzuki@google.com>
* NoteMapTest: Add missing @Test annotationsDave Borowitz2016-08-261-1/+7
| | | | | | | | | | The RepositoryTestCase hierarchy no longer comes from TestCase, so all test methods must have @Test. Fix one test that was broken but never run; fortunately this was just a typo in the test code. Change-Id: I3ac8ccdab5e2d5539c63d7b0a88d8bdb0c5ff66e Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Use FS#lastModified instead of File#lastModifiedMasaya Suzuki2016-08-243-15/+18
| | | | | | | | | | | | | | | This fixes the tests failed in JDK8. FS uses java.nio API to get file attributes. The timestamps obtained from that API are more precise than the ones from java.io.File#lastModified() since Java8. This difference accidentally makes JGit detect newly added files as smudged. Use the precised timestamp to avoid this false positive. Bug: 500058 Change-Id: I9e587583c85cb6efa7562ad6c5f26577869a2e7c Signed-off-by: Masaya Suzuki <masayasuzuki@google.com> Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
* Enhance ResetCommand to allow disabling reflog updateMatthias Sohn2016-08-171-0/+40
| | | | | | | This will be used by EGit for implementing commit amend in the staging view (see Idcd1efeeee8b3065bae36e285bfc0af24ab1e88f). Change-Id: Ice9ebbb1c0c3314c679f4db40cdd3664f61c27c3 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Merge "Skip cleaning inner repositories by default in CleanCommand"Christian Halstrick2016-08-071-0/+40
|\
| * Skip cleaning inner repositories by default in CleanCommandMatthaus Owens2016-08-041-0/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously jgit would attempt to clean git repositories that had not been committed by calling a non-recursive delete on them, which would fail as they are directories. This commit addresses that issue in the following ways. Repositories are skipped in a default clean, similarly to cgit and only cleaned when the force flag is applied. When the force flag is applied repositories are deleted using a recursive delete call. The force flag and setForce method are added here to CleanCommand to support this change. Bug: 498367 Change-Id: Ib6cfff65a033d0d0f76395060bf76719e13fc467 Signed-off-by: Matthaus Owens <matthaus@puppetlabs.com>
* | Merge "Add testCleanDirsWithSubmodule test to CleanCommandTest"Christian Halstrick2016-08-071-0/+28
|\|
| * Add testCleanDirsWithSubmodule test to CleanCommandTestMatthaus Owens2016-08-041-0/+28
| | | | | | | | | | | | | | | | | | This commit adds some test coverage to cleaning a repository with a submodule, which did not previously exist. Bug: 498367 Change-Id: Ia5c4e4cc53488800dd486f8556dc57656783f1c4 Signed-off-by: Matthaus Owens <matthaus@puppetlabs.com>
* | Shallow fetch/clone: Make --depth mean the total history depthTerry Parker2016-08-051-7/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | cgit changed the --depth parameter to mean the total depth of history rather than the depth of ancestors to be returned [1]. JGit still uses the latter meaning, so update it to match cgit. depth=0 still means a non-shallow clone. depth=1 now means only the wants rather than the wants and their direct parents. This is accomplished by changing the semantic meaning of "depth" in UploadPack and PackWriter to mean the total depth of history desired, while keeping "depth" in DepthWalk.{RevWalk,ObjectWalk} to mean the depth of traversal. Thus UploadPack and PackWriter always initialize their DepthWalks with "depth-1". [1] upload-pack: fix off-by-one depth calculation in shallow clone https://code.googlesource.com/git/+/682c7d2f1a2d1a5443777237450505738af2ff1a Change-Id: I87ed3c0f56c37e3491e367a41f5e555c4207ff44 Signed-off-by: Terry Parker <tparker@google.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-22 02:36:34 +0000