summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* JGit v4.2.0.201511101648-m1v4.2.0.201511101648-m1Matthias Sohn2015-11-1046-49/+49
| | | | | Change-Id: I659e9e95a96797f78f23669cfc5946c6b2d9c088 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Silence API errors for new methods added to BitmapBuilderMatthias Sohn2015-11-101-0/+14
| | | | | | | | | | | These API changes were introduced in f523f21e and 73474466. BitmapBuilder is an interface to be implemented by implementors of this interface. According to OSGi semantic versioning rules breaking API changes require update of the minor version only if implementors of the API have to be adapted and the changes do not affect clients of the API. Change-Id: If45d204181ea9bc788b6b57693ca17b1847564c7 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Add missing javadoc to bitmap index classesMatthias Sohn2015-11-102-1/+9
| | | | Change-Id: Ib9fd230c9465a719df53cfcb314d8b5015743928 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* Merge changes from topic 'nullable'Jonathan Nieder2015-11-099-22/+82
|\ | | | | | | | | | | | | * changes: Update dependencies to use the JGit-internal @Nullable Use the JGit-internal @Nullable annotation Add a JGit-internal Nullable type
| * Update dependencies to use the JGit-internal @NullableTerry Parker2015-11-097-19/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Update the project-specific Eclipse settings to replace the use of the org.eclipse.jdt.annotation.Nullable class the new JGit-specific @Nullable annotation. I verified that Eclipse reports errors when the return value of a method annotated with @org.eclipse.jgit.annotations.Nullable is dereferenced without a null check. Also remove the Maven and MANIFEST.MF dependencies on org.eclipse.jdt.annotation. Eclipse null analysis uses three annotations: @Nullable, @NonNull and @NonNullByDefault. All three are updated in this patch because it is invalid to set the Eclipse preferences to empty values. So far only @Nullable has been introduced in org.eclipse.jgit.annotations. My personal preference is to follow the advice in Effective Java and avoid the null-return idiom, and to avoid passing null values in general. This sets the expectation is that arguments and return types are assumed non-null unless otherwise documented. If that is the expectation, then consistent application of @NonNull is redundant and hurts readability by cluttering the code, obscuring the occasional @Nullable annotation that really requires attention. If the JGit community decides there is value in using the @NonNull and @NonNullByDefault annotations we can add them--this change configures Eclipse to use them. Change-Id: I9af1b786d1b44b9b0d9c609480dc842df79bf698 Signed-off-by: Terry Parker <tparker@google.com>
| * Use the JGit-internal @Nullable annotationTerry Parker2015-11-091-3/+5
| | | | | | | | | | | | | | | | Update existing @Nullable uses to use the JGit-internal version of the annotation. Change-Id: I95234ffad4c3110f9597fbd3a2760f653e22ecf7 Signed-off-by: Terry Parker <tparker@google.com>
| * Add a JGit-internal Nullable typeTerry Parker2015-11-091-0/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 847b3d1 enabled annotation-based NPE analysis to JGit. In so doing, it introduced a new dependency on the org.eclipse.jdt that is undesirable. Follow Gerrit's lead by adding an internal Nullable type (see https://gerrit.googlesource.com/gerrit/+/stable-2.11/gerrit-common/src/main/java/com/google/gerrit/common/Nullable.java). The javax.annotations.Nullable class uses a retention policy of RUNTIME, whereas the org.eclipse.jdt.annotation.Nullable class used a policy of CLASS. Since I'm not aware of tools that make use of the annotation at runtime I chose the CLASS policy. If in the future there is a benefit to retaining the annotations in the running binary we can update this class. Change-Id: I63dc8f9a6dc46b517cbde211bb5e2f8521a54d04 Signed-off-by: Terry Parker <tparker@google.com>
* | Make BitmapIndexImpl.CompressedBitmap publicJonathan Nieder2015-11-092-14/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PackWriterBitmapPreparer (which is in another package) is already well aware of the mapping between EWAHCompressedBitmaps and the higher-level CompressedBitmap objects of the BitmapIndexImpl API. Making the CompressedBitmap type public makes the translation more obvious and wouldn't break any abstractions that aren't already broken. So expose it. This is all under org.eclipse.jgit.internal so there are no API stability guarantees --- we can change the API if internals change (for example if some day there are bitmaps spanning multiple packs). In particular this means the confusing toBitmap helper can be removed. Change-Id: Ifb2e8804a6d5ee46e82a76d276c4f8507eaa2a4c
* | Make BitmapIndexImpl.CompressedBitmap, CompressedBitmapBuilder staticJonathan Nieder2015-11-091-78/+71
|/ | | | | | | | | | | | | | | A CompressedBitmap represents a pair (EWAH bit vector, PackIndex assigning bit positions to git objects). The bit vector is a member field and the PackIndex is implicit via the 'this' reference to the outer class. Make this clearer by making CompressedBitmap a static class and replacing the 'this' reference by an explicit field. Likewise for CompressedBitmapBuilder. Change-Id: Id85659fc4fc3ad82034db3370cce4cdbe0c5492c Suggested-by: Terry Parker <tparker@google.com>
* Skip redundant 'OR-reuse' step in tip commit bitmap setupJonathan Nieder2015-11-081-8/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When creating bitmaps during gc, the bitmaps in tipCommitBitmaps are built in setupTipCommitBitmaps using the following procedure: 0. create a bitmap ('reuse') that lists all ancestors of commits whose existing bitmaps will be reused. I will call this the reused part of history. 1. initialize a bitmap for each of the pack's "want"s by taking a copy of the 'reuse' bitmap and setting the bit corresponding to the one wanted commit. 2. walk through ancestors of wants, excluding the reused part of history. Add parents of visited commits to bitmaps that have those commits. 3. AND-NOT each tipCommitBitmap against the 'reuse' bitmap 4. Sort the bitmaps and AND-NOT each against the previous so they partition the new commits. The OR against 'reuse' in step 1 and the AND-NOT against 'reuse' cancel each other out, except when commits from the reused part of history are added to a bitmap in step 2. So avoid adding commits from the reused part of history in step 2 and skip the OR and AND-NOT. Performance impact (thanks to Terry for measuring): The initial "selecting bitmaps" phase of garbage collection decreased from (83 + 81 + 85) / 3 = 83 to (56 + 57 + 56) / 3 = 56.3, meaning nearly a ~50% speedup of that phase. Tested-by: Terry Parker <tparker@google.com> Change-Id: I26ea695809594347575d14a1d8e6721b8608eb9c
* Avoid repeated sort of tipCommitBitmapsJonathan Nieder2015-11-071-5/+6
| | | | Change-Id: I0feb2003f58776d50fab2d31d46ac98ae863bea8
* [style] Shorten line lengths and import order in bitmap codeTerry Parker2015-11-072-3/+5
| | | | | Change-Id: I420fcd308a97e30b8c74026d74b93ed3ec74bb3f Signed-off-by: Terry Parker <tparker@google.com>
* Inline PackWriterBitmapWalker.newRevFilter into callersJonathan Nieder2015-11-052-12/+10
| | | | | | | | Instead of using the newRevFilter helper, call the appropriate RevFilter constructor directly. This means one less hop to find documentation about what the RevFilter will do. Change-Id: Ida6ff1c0457a47a1bd1e4ed0fd1dd42a616d214f
* Convert remaining callers of BitmapBuilder.add to use .addObjectJonathan Nieder2015-11-052-3/+3
| | | | | | | | | | | | When setupTipCommitBitmaps is called, writeBitmaps does not have any bitmaps saved, so these calls to .add always add a single commit and do not OR in a bitmap. The objects returned by nextObject after a commit walk is finished are trees and blobs. Non-commit objects do not have bitmaps associated so the call to .add also can only add a single object. Change-Id: I7b816145251a7fa4f1fffe0d03644257ea7f5440
* Merge changes I57b1d7c1,I590ac460Jonathan Nieder2015-11-051-20/+84
|\ | | | | | | | | | | * changes: Use .addObject and .or instead of .add in AddToBitmapFilter Replace anonymous BitmapRevFilter subclasses with explicit classes
| * Use .addObject and .or instead of .add in AddToBitmapFilterJonathan Nieder2015-11-051-2/+18
| | | | | | | | | | | | | | | | This is the caller that the BitmapBuilder.add method was designed around. Moving away from .add makes it more verbose but hopefully clearer. Change-Id: I57b1d7c1dc8fb800b242b76c606922b5aa36b9b2
| * Replace anonymous BitmapRevFilter subclasses with explicit classesJonathan Nieder2015-11-051-20/+68
| | | | | | | | | | | | | | | | This puts the code for include() in each RevFilter returned by newRevFilter in one place and should make the code easier to understand and modify. Change-Id: I590ac4604b61fc1ffe7aba2ed89f8139847ccac3
* | Merge "Fix imports in DfsInserterTest"Matthias Sohn2015-11-051-10/+9
|\ \
| * | Fix imports in DfsInserterTestMatthias Sohn2015-11-051-10/+9
| | | | | | | | | | | | | | | | | | | | | - remove unused import of AnyObjectId - auto-sort import statements Change-Id: I1c7cec2734bd58370a7dfae70a6a4ccbe3e304ce Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | | Merge changes Ia95da478,I2773aa94,Ib745645f,I92c65f34,Ibb714002, ...Jonathan Nieder2015-11-054-25/+124
|\ \ \ | |/ / |/| / | |/ | | | | | | | | | | | | | | | | | | * changes: Remove BitmapRevFilter.getCountOfLoadedCommits Make BitmapBuilder.getBitmapIndex public Deprecate BitmapBuilder.add and introduce simpler addObject method Add @Override annotations to BitmapIndexImpl Rely on bitmap RevFilter to filter walk during bitmap selection Use 'reused' bitmap to filter walk during bitmap selection Rely on bitmap RevFilter to filter tip commit setup walk Use 'reused' bitmap to filter tip commit setup walk Include ancestors of reused bitmap commits in reuse bitmap again
| * Remove BitmapRevFilter.getCountOfLoadedCommitsJonathan Nieder2015-11-051-8/+8
| | | | | | | | | | | | | | The count of loaded commits is equal to the number of commits returned by the walk. Simplify BitmapRevFilter by counting them in the caller. Change-Id: Ia95da47831d9e89d6f8068470ec4529aaabfa7dd
| * Make BitmapBuilder.getBitmapIndex publicJonathan Nieder2015-11-052-1/+9
| | | | | | | | | | | | | | | | Every Bitmap in current JGit code has an associated BitmapIndex. Make it public in BitmapBuilder to make retrieving bitmaps to OR in from that index easier. Change-Id: I2773aa94d8b67f12194608e6317c0792a5de21e2
| * Deprecate BitmapBuilder.add and introduce simpler addObject methodJonathan Nieder2015-11-052-4/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The BitmapIndex.BitmapBuilder.add API is subtle: /** * Adds the id and the existing bitmap for the id, if one * exists, to the bitmap. * * @return true if the value was not contained or able to be * loaded. */ boolean add(AnyObjectId objectId, int type); Reading the name of the method does not make it obvious what it will do. Does it add the named object to the bitmap, or all objects reachable from it? It depends on whether the BitmapIndex owns an existing bitmap for that object. I did not notice this subtlety when skimming the javadoc, either. This resulted in enough confusion to subtly break the bitmap building code (see change I30844134bfde0cbabdfaab884c84b9809dd8bdb8 for details). So discourage use of the add() API by deprecating it. To replace it, provide a addObject() method that adds a single object. This way, callers can decide whether to use addObject() or or() based on the context. For example, if (bitmap.add(c, OBJ_COMMIT)) { for (RevCommit p : c.getParents()) { rememberToAlsoHandle(p); } } can be replaced with if (bitmap.contains(c)) { // already included } else if (index.getBitmap(c) != null) { bitmap.or(index.getBitmap(c)); } else { bitmap.addObject(c, OBJ_COMMIT); for (RevCommit p : c.getParents()) { rememberToAlsoHandle(p); } } which is more verbose but makes it clearer that the behavior depends on the content of index.getBitmaps(). Change-Id: Ib745645f187e1b1483f8587e99501dfcb7b867a5
| * Add @Override annotations to BitmapIndexImplJonathan Nieder2015-11-051-0/+16
| | | | | | | | | | | | | | | | | | This makes it easier to distinguish between implementations of methods from the interface from helpers internal to org.eclipse.jgit.internal.storage.*. This was illegal in Java 5 but JGit requires newer Java these days. Change-Id: I92c65f3407a334acddd32ec9e09ab7d1d39c4dc6
| * Rely on bitmap RevFilter to filter walk during bitmap selectionJonathan Nieder2015-11-051-3/+0
| | | | | | | | | | | | | | | | This RevWalk filters out reused bitmap commits via the 'reuse' bitmap. Avoid possible wasted time and complexity by not also redundantly marking them UNINTERESTING. Change-Id: Ibb714002ddac599963d148a9aab90645fcc73141
| * Use 'reused' bitmap to filter walk during bitmap selectionJonathan Nieder2015-11-051-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When building fullBitmap in order to determine which ancestor chain to add this commit to, we were excluding the ancestors of reusedCommits using markUninteresting. This use of markUninteresting is a bit wasteful because we already have a bitmap indicating exactly which commits should be excluded (which can save some walking). Use it. A separate commit will remove the now-redundant markUninteresting call. No behavior change intended (except for performance improvement). Change-Id: I1112641852d72aa05c9a8bd08a552c70342ccedb
| * Rely on bitmap RevFilter to filter tip commit setup walkJonathan Nieder2015-11-051-1/+0
| | | | | | | | | | | | | | | | This RevWalk filters out reused bitmap commits via the 'reuse' bitmap. Avoid possible wasted time and complexity by not redundantly marking them UNINTERESTING any more. Change-Id: If467ccd1d75e17cf9367b2a0399fca3f9d52adf9
| * Use 'reused' bitmap to filter tip commit setup walkJonathan Nieder2015-11-051-0/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When garbage collecting, we decide to reuse some bitmaps in older history from the previous pack to save time. The remainder of commit selection only involves commits not covered by those bitmaps. Currently we carry that out in two ways: 1. by building a bitmap representing the already-covered commits, for easy containment checks and AND-NOT-ing against 2. by marking the reused bitmap commits as uninteresting in the RevWalk that finds new commits The mechanism in (2) is less efficient than (1): rw.next() will walk back from reused bitmap commits to check whether the commit it is about to emit is an ancestor of them, when using the bitmap from (1) would let us perform the same check with a single contains() call. Add a RevFilter teaching the RevWalk to perform that same check directly using the bitmap from (1). The next time the RevWalk is used, a different RevFilter is installed so this does not break that. A later commit will drop the markUninteresting calls. No functional change intended except a possible speedup. Change-Id: Ic375210fa69330948be488bf9dbbe4cb0d069ae6
| * Include ancestors of reused bitmap commits in reuse bitmap againJonathan Nieder2015-11-032-5/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until 320a4142 (Update bitmap selection throttling to fully span active branches, 2015-10-20), setupTipCommitBitmaps contained code along the following lines: for (PackBitmapIndexRemapper.Entry entry : bitmapRemapper) { if (!reuse(entry)) continue; RevCommit rc = (RevCommit) rw.peel(rw.parseAny(entry)); reuseCommits.add(new BitmapCommit(rc)); EWAHCompressedBitmap bitmap = remap.ofObjectType(remap.getBitmap(rc), OBJ_COMMIT); writeBitmaps.addBitmap(rc, bitmap, 0); reuse.add(rc, OBJ_COMMIT); } writeBitmaps.clearBitmaps(); // Remove temporary bitmaps This loop OR-ed together bitmaps for commits whose bitmaps would be reused. A subtle point is the use of the add() method, which ORs in a bitmap from the BitmapIndex when it exists and falls back to OR-ing in a single bit when that bitmap does not exist in the BitmapIndex. Commit 320a4142 removed the addBitmap step, so the bitmap does not exist in the BitmapIndex and the fallback behavior is triggered. Simplify and restore the intended behavior by avoiding use of the subtle use of the add() method --- use or() directly instead. Change-Id: I30844134bfde0cbabdfaab884c84b9809dd8bdb8
* | Insert duplicate objects to prevent race during garbage collection.Mike Williams2015-11-043-8/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to this change, DfsInserter would not insert an object into a pack if it already existed in another pack in the repository, even if that pack was unreachable. Consider this sequence of events: - Object FOO is pushed to a repository. - Subsequent ref changes make FOO UNREACHABLE_GARBAGE. - FOO is subsequently re-inserted using a DfsInserter, but skipped due to existing in UNREACHABLE_GARBAGE. - The repository is repacked; FOO will not be written into a new pack because it is not yet reachable from a reference. If the UNREACHABLE_GARBAGE packs are deleted, FOO disappears. - A reference is updated to reference FOO. This reference is now broken as FOO was removed when the repacking process deleted the UNREACHABLE_GARBAGE pack that stored the only copy of FOO. The garbage collector can't safely delete the UNREACHABLE_GARBAGE pack because FOO might be in the middle of being re-inserted/re-packed. This change writes a duplicate copy of an object if it only exists in UNREACHABLE_GARBAGE. This "freshens" the object to give it a chance to survive long enough to be made reachable through a reference. Change-Id: I20f2062230f3af3bccd6f21d3b7342f1152a5532 Signed-off-by: Mike Williams <miwilliams@google.com>
* | Merge "Delta compression: reuse DeltaTask.getAdjustedWeight()"Jonathan Nieder2015-11-042-3/+2
|\ \
| * | Delta compression: reuse DeltaTask.getAdjustedWeight()Terry Parker2015-11-032-3/+2
| | | | | | | | | | | | | | | Change-Id: I07ed5207b175735b4e2c46edf652cc35908dad02 Signed-off-by: Terry Parker <tparker@google.com>
* | | Merge "[performance] Speed up delta packing"Shawn Pearce2015-11-041-8/+15
|\| | | |/ |/|
| * [performance] Speed up delta packingTerry Parker2015-11-031-8/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When packing is able to reuse lots of deltas from existing packs, those objects are marked as "doNotAttemptDelta" and do not contribute to DeltaTask's computeTopPaths() "totalWeight" calculation. In the extreme case when all packs are reusable, "totalWeight" will be zero. DeltaTask.partitionTasks() uses "totalWeight" to determine a "weightPerThread" size it uses to set up DeltaTasks. When "totalWeight" is small, partitionTasks() ends up creating a DeltaTask for every unique path. For a large repository, the small "weightPerThread" can result in the creation of >100k tasks (for the MSM 3.10 Linux repository, the count was ~150k). This makes the "task stealing" mechanism in DeltaTask very inefficient, because every attempt to steal work does a linear walk through all tasks, searching for the one with the most work remaining, which is O(N^2) comparisons. For the MSM 3.10 repository when all deltas were reusable, PackWriter.parallelDeltaSearch() took (1615+1633+1458)/3 = 1568 seconds. The error is that DeltaTask treats the weights of objects marked as "doNotAttemptDelta" inconsistently. It ignores the weights when calculating "totalWeight" but uses them when partitioning the tasks. The fix is to also ignore them when partitioning the tasks. With this patch applied, PackWriter.parallelDeltaSearch() on the MSM 3.10 repository when all deltas are reused went from taking 1568 seconds to 62ms (>25k speedup). This patch also fixes a totalWeight initialization error in DeltaTask.computeTopPaths(). Change-Id: I2ae37efa83bca42b0e716266ae6aa9d182e76d9c Signed-off-by: Terry Parker <tparker@google.com>
* | Merge "Decrease indentation in setupTipCommitBitmaps"Jonathan Nieder2015-11-031-23/+27
|\ \
| * | Decrease indentation in setupTipCommitBitmapsJonathan Nieder2015-11-031-23/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Avoid leaving the reader in suspense by handling the unusual (!RevCommit) case first. As a nice side effect, there is less nesting to keep track of in the rest of the loop body. No functional change intended. Change-Id: I1580de444fccde08070f696218c12041151a924a
* | | Merge "[style] Add braces to DeltaTask"Jonathan Nieder2015-11-031-15/+29
|\ \ \ | | |/ | |/|
| * | [style] Add braces to DeltaTaskTerry Parker2015-11-031-15/+29
| | | | | | | | | | | | | | | Change-Id: I3306cc77544dec6d9273b2c35b8db0ed43799992 Signed-off-by: Terry Parker <tparker@google.com>
* | | Add support for pre-push hooksChristian Halstrick2015-11-024-2/+238
| | | | | | | | | | | | | | | | | | | | | | | | | | | When the file <git-dir>/hooks/pre-push exists make sure that is is executing during a push. The pre-push hook runs during git push, after the remote refs have been updated but before any objects have been transferred. Change-Id: Ibbb58ee3227742d1a2f913134ce11e7a135c7f4c
* | | Enhance FS.runProcess() to support stdin-redirection and binary dataChristian Halstrick2015-11-022-40/+242
| |/ |/| | | | | | | | | | | | | In order to support filters in gitattributes FS.runProcess() is made public. Support for stdin redirection has been added. Support for binary data on stdin/stdout (as used be clean/smudge filters) has been added. Change-Id: Ice2c152e9391368dc5748d7b825a838e3eb755f9 Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* | Cleaned up various readPipe() threading issuesAndrey Loskutov2015-11-011-25/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed random errors in discoverGitSystemConfig() on Linux where the process error stream was closed by readPipe() before or while GobblerThread was reading from it. Marked readPipe() as @Nullable and fixed potential NPE in discoverGitSystemConfig() on readPipe() return value. Fixed process error output randomly mixed with other threads log messages. Change-Id: Id882af2762cfb75f010f693b2e1c46eb6968ee82 Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
* | Don't report errors logged by FS with "debug" levelAndrey Loskutov2015-10-311-21/+7
|/ | | | | Change-Id: I6a10116cd2e6b58d2300a9e741afe2eeac719b03 Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
* Building bitmaps: Simplify the logic to sort by chainsTerry Parker2015-10-291-15/+8
| | | | | Change-Id: I3da98e85107154c159093c138893f54dfa7ef435 Signed-off-by: Terry Parker <tparker@google.com>
* Merge "Pack bitmaps: improve readability"Jonathan Nieder2015-10-291-26/+42
|\
| * Pack bitmaps: improve readabilityTerry Parker2015-10-281-26/+42
| | | | | | | | | | | | | | | | Add comments and rename variables in PackWriterBitmapPreparer to improve readability. Change-Id: I49e7a1c35307298f7bc32ebfc46ab08e94290125 Signed-off-by: Terry Parker <tparker@google.com>
* | Merge "Bitmap generation: Add a test of ordering commits by "chains""Jonathan Nieder2015-10-292-139/+271
|\ \
| * | Bitmap generation: Add a test of ordering commits by "chains"Terry Parker2015-10-282-139/+271
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When commits are selected for bitmap generation, they are reordered so that related "chains" of commits are grouped together. Chains are "subbranches" of commits that may branch off of and re-merge with the main line. Grouping by chains means that the XOR difference between consecutive selected commits will be smaller, resulting in better run-length compression of the XORed bitmaps. Add a new testSelectionOrderingWithChains() test in a new GcCommitSelectionTest test class. Also move related GC commit selection tests out of GcBasicPackingTest and into GcCommitSelectionTest. Change-Id: I8e80cac29c4ca8193b41c9898e5436c22a659f11 Signed-off-by: Terry Parker <tparker@google.com>
* | | Merge "reset command should support the -- <paths> parameters"Christian Halstrick2015-10-294-20/+165
|\ \ \
| * | | reset command should support the -- <paths> parametersKaloyan Raev2015-10-294-20/+165
| | |/ | |/| | | | | | | | | | | | | Bug: 480750 Change-Id: Ia85b1aead03dcf2fcb50ce0391b656f7c60a08d4 Signed-off-by: Kaloyan Raev <kaloyan.r@zend.com>
* | | JGit CLI should check if calling itself when invoking native git exeKaloyan Raev2015-10-291-0/+8
| |/ |/| | | | | | | | | Bug: 480782 Change-Id: I0d7f7a648671e7ff678f2b19fe39b85f8835c061 Signed-off-by: Kaloyan Raev <kaloyan.r@zend.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-06 04:45:30 +0000