Expose the following bitmap selection parameters via PackConfig:
"bitmapContiguousCommitCount", "bitmapRecentCommitCount",
"bitmapRecentCommitSpan", "bitmapDistantCommitSpan",
"bitmapExcessiveBranchCount", and "bitmapInactiveBranchAge".
The value of bitmapContiguousCommitCount, whereby bitmaps are
created for the most recent N commits in a branch, has never
been verified. If experiments show that they are not valuable,
then we can simplify the implementation so that there is only
a concept of recent and distant commit history (defined by
"bitmapRecentCommitCount"), and the only controls we need are
"bitmapRecentCommitSpan" and "bitmapDistantCommitSpan".
Change-Id: I288bf3f97d6fbfdfcd5dde2699eff433a7307fb9
Signed-off-by: Terry Parker <tparker@google.com>
Replace the “bitmapCommitRange” parameter that was recently introduced
with two new parameters: “bitmapExcessiveBranchCount” and
“bitmapInactiveBranchAgeInDays”. If the count of branches does not
exceed “bitmapExcessiveBranchCount”, then the current algorithm is kept
for all branches.
If the branch count is excessive, then the commit time for the tip
commit for each branch is used to determine if a branch is “inactive”.
"Active" branches get full commit selection using the existing
algorithm. "Inactive" branches get fewer bitmaps near the branch tips.
Introduce a "contiguousCommitCount" parameter that always enforces that
the N most recent commits in a branch are selected for bitmaps. The
previous nextSelectionDistance() algorithm created anywhere from 1-100
contiguous bitmaps at branch tips.
For example, consider a branch with commits numbering 0-300, with 0
being the most recent commit. If the most recent 200 commits are not
merge commits and the 200th commit was the last one selected,
nextSelectionDistance() returned 100, causing commits 200-101 to be
ignored. Then a window of size 100 was evaluated, searching for merge
commits. Since no merge commits are found, the next commit (commit 0)
was selected, for a total of 1 commit in the topmost 100 commits.
If instead the 250th commit was selected, then by the same logic
commit 50 is selected. At that point nextSelectionDistance() switches to
selecting consecutive commits, so commits 0-50 in the topmost 100
commits are selected. The "contiguousCommitCount" parameter provides
more determinism by always selecting a constant number or topmost
commits.
Add an optimization to break out of the inner loop of selectCommits() if
all of the commits for the current branch have already been found.
When reusing bitmaps from an existing pack, remove unnecessary
populating and clearing of the writeBitmaps/PackBitmapIndexBuilder.
Add comments to PackWriterBitmapPreparer, rename methods and variables
for readability.
Add tests for bitmap selection with and without merge commits and with
excessive branch pruning triggered.
Note: I will follow up with an additional change that exposes the new
parameters through PackConfig.
Change-Id: I5ccbb96c8849f331c302d9f7840e05f9650c4608
Signed-off-by: Terry Parker <tparker@google.com>
Since Git 2.6 wildcard restrictions for refspecs have been loosened:
refspecs like "refs/heads/*foo:refs/heads/foo*" are valid now.
See Git commit 8d3981ccbed9fc211b4e67105015179d9d2a5692
Change-Id: Icb78afbd282c425173b3a7bc10eadc4015689bb8
Signed-off-by: Marc Strapetz <marc.strapetz@syntevo.com>
LocalDiskRepositoryTestCase and TestRepository have competing ideas
about time. Push them into MockSystemReader so they can
cooperate.
Rename getClock() methods that return Dates to getDate().
Change-Id: Ibbd9fe7f85d0064b0a19e3b675b9718a9e67c479
Signed-off-by: Terry Parker <tparker@google.com>
Building on top of https://git.eclipse.org/r/#/c/56391/
Here we preserve compatibility with JetS3t
and add 2 new native JGit encryption implementations.
For reference, see connection configuration files:
* Version 0: jgit-s3-connection-v-0.properties
* Version 1: jgit-s3-connection-v-1.properties
* Version 2: jgit-s3-connection-v-2.properties
Change-Id: I713290bcacbe92d88e5ef28ce137de73dd1abe2f
Signed-off-by: Andrei Pozolotin <andrei.pozolotin@gmail.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
See previous attempt: https://git.eclipse.org/r/#/c/16674/
Here we preserve as much of JetS3t mode as possible
while allowing to use new Java 8+ PBE algorithms
such as PBEWithHmacSHA512AndAES_256
Summary of changes:
* change pom.xml to control long tests
* add WalkEncryptionTest.launch to run long tests
* add AmazonS3.Keys to to normalize use of constants
* change WalkEncryption to support AES in JetS3t mode
* add WalkEncryptionTest to test remote encryption pipeline
* add support for CI configuration for live Amazon S3 testing
* add log4j based logging for tests in both Eclipse and Maven build
To test locally, check out the review branch, then:
* create amazon test configuration file
* located your home dir: ${user.home}
* named jgit-s3-config.properties
* file format follows AmazonS3 connection settings file:
accesskey = your-amazon-access-key
secretkey = your-amazon-secret-key
test.bucket = your-bucket-for-testing
* finally:
* run in Eclipse: WalkEncryptionTest.launch
* or
* run in Shell: mvn test --define test=WalkEncryptionTest
Change-Id: I6f455fd9fb4eac261ca73d0bec6a4e7dae9f2e91
Signed-off-by: Andrei Pozolotin <andrei.pozolotin@gmail.com>
At least on Windows the test failed each second time on the last assert.
Adding a small timeout before gc.prune() makes the test stable again.
Change-Id: I23d98dd565912c58dcf2f24f3ebc24824670cff3
Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
RepoCommandTest was failing because of open file handle left.
IgnoreNodeTest was failing because of problems with creation of files
with trailing spaces on Windows.
HookTest was failing because of wrong line delimiter.
Change-Id: I34f074ac447eb4c3ada8b250309bb568b426189d
Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
If the checkout path is currently a non-empty directory (and was a link
or a regular file before), this directory will be removed before
performing checkout, but only if the checkout path is specified.
Bug: 474973
Change-Id: Ifc6c61592d9b54d26c66367163acdebea369145c
Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
A bitmap index contains bitmaps for a set of commits in a pack file.
Creating a bitmap for every commit is too expensive, so heuristics
select the most "important" commits. The most recent commits are the
most valuable. To clone a repository only those for the branch tips are
needed. When fetching, only commits since the last fetch are needed.
The commit selection heuristics generally work, but for some
repositories the number of selected commits is prohibitively high. One
example is the MSM 3.10 Linux kernel. With over 1 million commits on
2820 branches, the current heuristics resulted in +36k selected commits.
Each uncompressed bitmap for that repository is ~413k, making it
difficult to complete a GC operation in available memory.
The benefit of creating bitmaps over the entire history of a repository
like the MSM 3.10 Linux kernel isn't clear. For that repository, most
history for the last year appears to be in the last 100k commits.
Limiting bitmap commit selection to just those commits reduces the count
of selected commits from ~36k to ~10.5k. Dropping bitmaps for older
commits does not affect object counting times for clones or for fetches
on clients that are reasonably up-to-date.
This patch defines a new "bitmapCommitRange" PackConfig parameter to
limit the commit selection process when building bitmaps. The range
starts with the most recent commit and walks backwards. A range of 10k
considers only the 10000 most recent commits. A range of zero creates
bitmaps only for branch tips. A range of -1 (the default) does not limit
the range--all commits in the pack are used in the commit selection
process.
Change-Id: Ied92c70cfa0778facc670e0f14a0980bed5e3bfb
Signed-off-by: Terry Parker <tparker@google.com>
Previously the method DirCacheCheckoutTest#assertWorkDir() silently
skipped over empty folders. If tests would have left unexpected empty
folders in the worktree this would be overlooked. Now empty folders have
to be specified by something like mkmap("<foldername>", "/", ...]
Change-Id: Idb8b270e92daf02ecdc381d148a5958bd83ec057
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
On a server also running Gerrit that is using RepoCommand to
convert from an XML manifest to a git submodule superproject
periodically, it would be handy to be able to use Gerrit's
submodule subscription feature[1] to update the superproject
automatically between RepoCommand runs as changes are merged
in each subprojects.
This requires setting the 'branch' field for each submodule
so that Gerrit knows what branch to watch. Add an option to
do that.
Setting the branch field also is useful for plain Git users,
since it allows them to use "git submodule update --remote" to
manually update all submodules between RepoCommand runs.
[1] https://gerrit-review.googlesource.com/Documentation/user-submodules.html
Change-Id: I1a10861bcd0df3b3673fc2d481c8129b2bdac5f9
Signed-off-by: Stefan Beller <sbeller@google.com>
This patch makes JGit parsing of ignore rules containing unmatched '['
bracket compatible to the Git CLI.
Since '[' starts character group, Git tries to parse the ignore rule as
a shell glob pattern and if the character group is not closed, the glob
pattern is invalid and so the ignore rule never matches anything.
See also http://article.gmane.org/gmane.comp.version-control.git/278699.
Bug: 478490
Change-Id: I734a4d14fcdd721070e3f75d57e33c2c0700d503
Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
This test case was developed in the scope of bug 478065.
Bug: 478065
Change-Id: Ibcce1ed375d4a6ba05461e6c6b287d16752fa681
Signed-off-by: Sébastien Arod <sebastien.arod@gmail.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
An attempt to re-implement not well documented Git CLI behavior for
patterns with backslashes.
It looks like Git silently ignores all \ characters in ignore rules, if
they are NOT covered by 3 cases described in [1]:
{quote}
1) ... Put a backslash ("\") in front of the first hash for patterns
that begin with a hash.
...
2) Trailing spaces are ignored unless they are quoted with backslash
("\").
...
3) Put a backslash ("\") in front of the first "!" for patterns that
begin with a literal "!", for example, "\!important!.txt".
{quote}
Undocumented also is the fact that backslash itself can be escaped by
backslash.
So \h\e\l\l\o\.t\x\t rule matches hello.txt and a\\\\b a\b in Git CLI.
Additionally, the glob parser [2] knows special meaning of backslash:
{quote}
One can remove the special meaning of '?', '*' and '[' by preceding
them by a backslash, or, in case this is part of a shell command
line, enclosing them in quotes. Between brackets these characters
stand for themselves. Thus, "[[?*\]" matches the four characters
'[', '?', '*' and '\'.
{quote}
[1] https://www.kernel.org/pub/software/scm/git/docs/gitignore.html
[2] http://man7.org/linux/man-pages/man7/glob.7.html
Bug: 478065
Change-Id: I3dc973475d1943c5622103701fa8cb3ea0684e3e
Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
Currently we fail to properly recognize character group if the pattern
before character group contains opening bracket.
See comment from Sebastien Arod on https://git.eclipse.org/r/56678/
Change-Id: I70d3657a2a328818ea2bdc1409d18ecb3a85825b
Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
Current DiffFormat behavior regarding submodules (aka git links) is
incorrect. The "Subproject commit <sha1>" appears as part of the diff
header, rather than as its own hunk.
--> From JGit implementation
diff --git a/plugins/cookbook-plugin b/plugins/cookbook-plugin
index b9d3ca8..ec6ed89 160000
--- a/plugins/cookbook-plugin
+++ b/plugins/cookbook-plugin
-Subproject commit b9d3ca8a65030071e28be19296ba867ab424fbbf
+Subproject commit ec6ed89c47ba7223f82d9cb512926a6c5081343e
--> From C Git 2.5.2
diff --git a/plugins/cookbook-plugin b/plugins/cookbook-plugin
index b9d3ca8..ec6ed89 160000
--- a/plugins/cookbook-plugin
+++ b/plugins/cookbook-plugin
@@ -1 +1 @@
-Subproject commit b9d3ca8a65030071e28be19296ba867ab424fbbf
+Subproject commit ec6ed89c47ba7223f82d9cb512926a6c5081343e
The current way of processing submodules results in no hunk header and
includes the contents of the hunk as part of the headers. To fix this, we
can't just have our writeGitLinkDiffText output the hunk header. We have
to change the flow so that the raw text gets parsed as a diff. The easiest
way to do this is to fake the RawText in the FormatResult when we have a
GITLINK.
It should be noted that it seems possible for there to be a difference
between a GITLINK and a non-GITLINK, but I don't think this can happen in
practice, so I don't think we need to worry too much about it.
This patch also fixes up the test for GitLink headers, as the test was
for the old behavior. My setup has 3 other failing tests which may or
may not be the result of environmental changes. However, the same tests
fail without this commit, so I do not believe they are related.
Bug: 477759
Change-Id: If13f7b406904fad814416c93ed09ea47ef183337
Signed-off-by: Jacob Keller <jacob.keller@gmail.com>
Ignore rules should escape $^(){}+| chars if using regular expressions,
because they should be treated literally if they aren't part of a
character group.
Bug: 478055
Change-Id: Ic7276442d7f8f02594b85eae1ef697362e62d3bd
Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
Fix the unit tests to not do boxing by using assertEquals(int, int)
instead of assertThat with a matcher.
Change-Id: I5412fe2f72c8ea0227b9ff3a3352ccb555e22231
Signed-off-by: Hugo Arès <hugo.ares@ericsson.com>
When we have a URI that contains an empty path component (that is
it only contains a "/") we want to fall back to the host as
humanish name.
This change is according to the behavior of upstream git, which
falls back on the hostname when guessing directory names for
newly cloned repositories (see [1] for the discussion).
[1] http://article.gmane.org/gmane.comp.version-control.git/274669
Change-Id: I44400c6ab72a2722d2155d53d63671bd867d6c44
Signed-off-by: Patrick Steinhardt <ps@pks.im>
If no refs match the input list and we are writing to a batch,
the returned new commit from write() will match the current commit.
Adding a command to the batch for this case is harmless as it will
succeed, but it's more straightforward to just skip adding a command
in this case.
Add tests or the combination of saving matching refs and saving to a
batch.
Change-Id: I6837389b08e6c80bc2d4c9e9c506d07293ea5fb2
- use NIO2's Files.move() to reimplement rename()
- provide a second method accepting CopyOptions which can be used to
request atomic move.
Change-Id: Ibcf722978e65745218a1ccda45344ca295911659
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The WorkingTreeIterator.isEntryIgnored() should use originally requested
file mode while descending to the file tree root and checking ignore
rules. Original code asking isEntryIgnored() on a file was using
directory mode instead if the .gitignore was not located in the same
directory.
Bug: 473506
Change-Id: I9f16ba714c3ea9e6585e9c11623270dbdf4fb1df
Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
When during Merge for a certain path OURS & BASE contains a file and
THEIRS contains a folder there was a bug in JGit leading to unnecessary
conflicts. This commit fixes it and adds a test for this situation.
Bug: 472693
Change-Id: I71fac5a6a2ef926c01adc266c6f9b3275e870129
Also-by: Clemens Buchacher <drizzd@aon.at>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
According to [1] leading spaces are allowed in ignore rules and trailing
spaces are allowed too if they are escaped via backslash.
[1] https://www.kernel.org/pub/software/scm/git/docs/gitignore.html
Bug: 472762
Change-Id: I5e3ae5599cb9e5d80072f38c82c20cbc9475a18a
Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
According to [1] backslash can escape leading special characters '#' and
'!' in ignore rules, so that they are treated literally.
[1] https://www.kernel.org/pub/software/scm/git/docs/gitignore.html
Bug: 463581
Change-Id: I4c02927413a9c63ea5dbf2954877080d902ec1b2
Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
While checking if we should consider an ignore rule without '[]'
brackets as a regular expression, check if the backslash escapes one of
the glob special characters '?', '*', '[', '\\'. If not, backslash is
not a part of a regex and should be treated literally.
Bug: 463581
Change-Id: I85208c7f85246fbf6c5029ce3c8b7bb8f4dbd947
Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
Consider a BatchRefUpdate produced by Gerrit Code Review, where the
original command pushed over the wire might refer to
"refs/for/master", but that command is ignored and replaced with some
additional commands like creating "refs/changes/34/1234/1". We do not
want to store the cert in "refs/for/master@{cert}", since that may
lead someone looking to the ref to the incorrect conclusion that that
ref exists.
Add a separate put method that takes a collection of commands, and
only stores certs on those refs that have a matching command in the
cert.
Change-Id: I4661bfe2ead28a2883b33a4e3dfe579b3157d68a
37a1e4be moved this constant causing the following error message in
Eclipse: "The static field LocalDiskRepositoryTestCase.CONTENT should be
accessed directly".
Change-Id: I4ceb57a30f2e5a8f7e55109ef260a244ed5e7044
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Inspired by a proposal from gitolite[1], where we store a file in
a tree for each ref name, and the contents of the file is the latest
push cert to affect that ref.
The main modification from that proposal (other than lacking the
out-of-git batching) is to append "@{cert}" to filenames, which allows
storing certificates for both refs/foo and refs/foo/bar. Those
refnames cannot coexist at the same time in a repository, but we do
not want to discard the push certificate responsible for deleting the
ref, which we would have to do if refs/foo in the push cert tree
changed from a tree to a blob.
The "@{cert}" syntax is at least somewhat consistent with
gitrevisions(7) wherein @{...} describe operators on ref names.
As we cannot (currently) atomically update the push cert ref with the
refs that were updated, this operation is inherently racy. Kick the can
down the road by pushing this burden on callers.
[1] cf062b8bb6/contrib/hooks/repo-specific/save-push-signatures
Change-Id: Id3eb32416f969fba4b5e4d9c4b47053c564b0ccd
This will allow us to write the super project in a branch other than
master.
Change-Id: I578ed9ecbc6423416239e31ad644531dae9fb5c3
Signed-off-by: Yuxuan 'fishy' Wang <fishywang@google.com>
When pushing to an HTTP server using the C git client, I observed a
certificate lacking a pushee field. Handle this gracefully in the
parser.
Change-Id: I7f3c5fa78f2e35172a93180036e679687415cac4
We intend to store received push certificates somewhere, like a
particular ref in the repository in question. For reading data back
out, it will be useful to read push certificates (without pkt-line
framing) in a streaming fashion.
Change-Id: I70de313b1ae463407b69505caee63e8f4e057ed4
Discussion on the git mailing list has concluded[1] that the intended
behavior for all (non-sideband) portions of the receive-pack protocol
is for trailing LFs in pkt-lines to be optional. Go back to using
PacketLineIn#readString() everywhere.
For push certificates specifically, we agreed that the payload signed
by the client is always concatenated with LFs even though the client
MAY omit LFs when framing the certificate for the wire. This is still
reflected in the implementation of PushCertificate#toText().
[1] http://thread.gmane.org/gmane.comp.version-control.git/273175/focus=273412
Change-Id: I817231c4d4defececb8722142fea18ff42e06e44
ObjectId.fromString already throws InvalidObjectIdException for most
malformed object ids, but for this kind it previously threw
IllegalArgumentException. Since InvalidObjectIdException is a child of
IllegalArgumentException, callers that catch IllegalArgumentException
will continue to work.
Change-Id: I24e1422d51607c86a1cb816a495703279e461f01
Signed-off-by: Jonathan Nieder <jrn@google.com>
Add methods that allow to unregister repositories from the
RepositoryCache individually.
Bug: 470234
Change-Id: Ib918a634d829c9898072ae7bdeb22b099a32b1c9
Signed-off-by: Tobias Oberlies <tobias.oberlies@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
For loose objects an expiration date can be set which will save too
young objects from being deleted. Add the same for packfiles. Packfiles
which are too young are not deleted.
Bug: 468024
Change-Id: I3956411d19b47aaadc215dab360d57fa6c24635e
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
These differ subtly from a PersonIdent, because they can contain
anything that is a valid User ID passed to gpg --local-user. Upstream
git push --signed will just take the configuration value from
user.signingkey and pass that verbatim in both --local-user and the
pusher field of the certificate. This does not necessarily contain an
email address, which means the parsing implementation ends up being
substantially different from RawParseUtils.parsePersonIdent.
Nonetheless, we try hard to match PersonIdent behavior in
questionable cases.
Change-Id: I37714ce7372ccf554b24ddbff56aa61f0b19cbae
The signature is intended to be passed to a verification library such
as Bouncy Castle, which expects these lines to be present in order to
parse the signature.
Change-Id: I22097bead2746da5fc53419f79761cafd5c31c3b
The default behavior is to read a repository's signed push
configuration from that repo's config file, but this is not very
flexible when it comes to managing groups of repositories (e.g. with
Gerrit). Allow callers to override the configuration using a POJO.
Change-Id: Ib8f33e75daa0b2fbd000a2c4558c01c014ab1ce5
A non-bare clone command with null remote produces a
NullPointerException when trying to produce a refspec to fetch against.
In a bare repository, a null remote name is accepted by mistake,
producing a configuration with items like 'remote.url' instead of
'remote.<remote>.url'. This was never meant to work.
Instead, let's make setRemote(null) undo any previous setRemote calls
and re-set the remote name to DEFAULT_REMOTE, imitating C git clone's
--no-origin option.
While we're here, add some tests for setRemote working normally.
Change-Id: I76f502da5e677df501d3ef387e7f61f42a7ca238
Signed-off-by: Jonathan Nieder <jrn@google.com>
- 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
C git's receive-pack.c strips trailing newlines in command lists when
present[1], although send-pack.c does not send them, at least in the
case of command lists[2]. Change JGit to match this behavior.
Add tests.
This also fixes parsing of commands in the push cert, which, unlike
commands sent in the non-push case, always have trailing newlines.
[1] 7974889a05/builtin/receive-pack.c (L1380)
where packet_read_line chomps newlines:
7974889a05/pkt-line.c (L202)
[2] 7974889a05/send-pack.c (L470)
Change-Id: I4bca6342a7482a53c9a5815a94b3c181a479d04b
The new submodule layout where GITDIR of a submodule is located at
<parent-repo-GITDIR>/modules/<submodule-path> was only used during
clone. Teach SubmoduleAddCommand to use the new layout.
Bug: 469666
Change-Id: Ie97dc0607b71499560444616f362bccee9cce515
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Most relative-URL tests for SubmoduleInitCommand carry out the following
steps:
1. add a submodule at path "sub" to the index
2. set remote.origin.url in .git/config
3. configure .gitmodules, possibly using relative URLs, and see what
happens
resolveWorkingDirectoryRelativeUrl() is meant to test the fallback when
remote.origin.url is not set, to match C git which treats the URL as
relative to the cwd in that case. To do so, in step (2) it sets
remote.origin.url to null.
However, Config.setString when taking a null value does not actually
unset that value from the configuration --- it sets it to the empty
string. This means we are testing a behavior that C git never
supported. Use Config.unset instead.
Change-Id: I7af29fbbd333a2598843d62c320093c48b2ad972
Signed-off-by: Jonathan Nieder <jrn@google.com>
Move ObjectCountCallback and WriteAbortedException to package
org.eclipse.jgit.transport, so that they'll become public API.
Change-Id: I95e3cfaa49f3f7371e794d5c253cf6981f87cae0
Signed-off-by: Yuxuan 'fishy' Wang <fishywang@google.com>
This reverts commit 96eb3ee397, which
broke Gerrit tests that set a config value to 'null', serialize the
result, deserialize, and expect 'null' from Config.getString[1].
The intent of that commit was to make it possible to distinguish between
an absent and an empty config value, which we'll have to do with a new
method.
Revert the behavior change. Keep the tests from 428cb23f2de8, since
they test the behavior more precisely than the old tests did.
[1] https://gerrit-review.googlesource.com/68452
Change-Id: Ie8042f380ea0e34e3203e1991aa0feb2e6e44641
Signed-off-by: Jonathan Nieder <jrn@google.com>
Added callback in PackWriter and BundleWriter for the caller to get the
count of objects to write, and a chance to abort the write operation.
Change-Id: I1baeedcc6946b1093652de4a707fe597a577e526
Signed-off-by: Yuxuan 'fishy' Wang <fishywang@google.com>
exactRef(ref1, ref2, ref3) requests multiple specific refs in a single
lookup, which may be faster in some backends than looking them up one by
one.
firstExactRef generalizes getRef by finding the first existing ref from
the list of refs named. Its main purpose is for the default
implementation of getRef (finding the first existing ref in a search
path). Hopefully it can be useful for other operations that look for
refs in a search path (e.g., git log --notes=<name>), too.
Change-Id: I5c6fcf1d3920f6968b8b97f3d4c3a267258c4b86
Signed-off-by: Jonathan Nieder <jrn@google.com>
Unlike getRef(name), the new exactRef method does not walk the search
path. This should produce a less confusing result than getRef when the
exact ref name is known: it will not try to resolve refs/foo/bar to
refs/heads/refs/foo/bar even when refs/foo/bar does not exist.
It can be faster than both getRefs(ALL).get(name) and getRef(name)
because it only needs to examine a single ref.
A follow-up change will introduce a findRef synonym to getRef and
deprecate getRef to make the choice a caller is making more obvious
(exactRef or findRef, with the same semantics as getRefs(ALL).get and
getRefs(ALL).findRef).
Change-Id: If1bd09bcfc9919e7976a4d77f13184ea58dcda52
Signed-off-by: Jonathan Nieder <jrn@google.com>
This is a perfectly valid construction according to C git:
$ echo -en '[a]\nx =' > foo.config
$ git config -f foo.config a.x; echo $?
0
Change-Id: Icfcf8304adb43c79e2b8b998f8d651b2a94f6acb
The C git API and command line tools distinguish between a key having
the empty string as a value and no key being present in the config
file:
$ echo -e '[a]\nx =' > foo.config
$ git config -f foo.config a.x; echo $?
0
$ git config -f foo.config a.y; echo $?
1
Make JGit make the same distinction. This is in line with the current
Javadoc of getString, which claims to return "a String value from the
config, null if not found". It is more reasonable to interpret "x ="
in the above example as "found" rather than "missing".
We need to maintain the special handling of a key name with no "="
resolving to a boolean true, but "=" with an empty string is still not
a valid boolean.
Change-Id: If0dbb7470c524259de0b167148db87f81be2d04a
When CommitCommand.setOnly(path) is used a temporary index has to be
created containing only modifications for the specified pathes. The
process to fill this temporary index was broken because filling the
index was stopped when we reached the first untracked file. Instead the
process to fill the temporary index should continue until we processed
all pathes.
Bug: 451465
Change-Id: I22af50d70bd3b81e7c056358724956122b0d158d
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Otherwise MergeCommandTest using Sets doesn't compile in Eclipse since
adbcbc79 moved Sets from the "tst" to the "src" folder.
Change-Id: I661b987513365a8af0b568ec95b0898e5758f59f
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
ObjectReader release method was replaced by close method but
WindowCursor was still implementing release method.
To prevent the same mistake again, make ObjectReader close method
abstract to force sub classes to implement it.
Change-Id: I50d0d1d19a26e306fd0dba77b246a95a44fd6584
Signed-off-by: Hugo Arès <hugo.ares@ericsson.com>
Commit d3348e introduced few errors in Eclipse.
This commit cleans up the new API:
- fixes API error in RepoCommand after moving IncludedFileReader type
- fixes unused imports in RepoCommand & RepoCommandTest
- fix javadoc errors in ManifestParser & RepoProject
- makes three (implicitly final) fields in ManifestParser final.
Change-Id: I4185f451d97039d155391f62815bb9d3afe39fa6
Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
The repo xml manifest parser used in RepoCommand could also be useful for
others, so refactor to make it public.
Also this breaks backward compatibility slightly.
Change-Id: I5001bd2fe77541109fe32dbe2597a065e6ad585e
Signed-off-by: Yuxuan 'fishy' Wang <fishywang@google.com>
Test that
- the default ObjectFilter is ALL
- ObjectFilter affects nextObject() and not next()
- omitting a tree implies omitting its subtrees
- a blob or tree reached by another path is still returned
- ObjectFilter can be mixed with RevFilter
Change-Id: I144a53fe677070fff8c3ddf8cba07a848773bc1b
Signed-off-by: Jonathan Nieder <jrn@google.com>
A later patch will make use of this class in a org.eclipse.jgit.lib
test.
Change-Id: I2b268e6a5dbf12174201f45259f9f007686708d2
Signed-off-by: Jonathan Nieder <jrn@google.com>
Change-Id: I700540eec06efb24eeb09bfcb40420820c32d156
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The LRU chain management code was broken leading to situations where
the chain was incomplete. This prevented the cache from removing
items when it exceeded its memory target, causing a leak.
One case was repeated hit on the head of the chain. moveToHead(e)
was invoked linking the head back to itself in a cycle orphaning
the rest of the table.
Add some unit tests to cover this and a few other paths.
Change-Id: Ib27486eaa1b1d2bf1c745a56d0a5832bfb029322
Avoid always calling `sh -c umask` on startup, instead deferring
the invocation until the first time a working tree file needs to
use the execute bit. This allows servers using bare repos to avoid
a costly fork+exec for a value that is never used.
Store the umask as an int instead of two Boolean. This is slightly
smaller memory (one int vs. two references) and makes it easier for
an application to force setting the umask to a value that overrides
whatever the shell told JGit.
Simplify the code to bail by returning early when canExecute is
false, which is the common case for working tree files.
Change-Id: Ie713647615bc5bdf5d71b731a6748c28ea21c900
Despite being the primary author of RevWalk and ObjectWalk I still
fail to remember to setRetainBody(false) in application code using
an ObjectWalk to examine the graph.
Document the default for RevWalk is setRetainBody(true), where the
application usually wants the commit bodies to display or inspect.
Change the default for ObjectWalk to setRetainBody(false), as nearly
all callers want only the graph shape and do not need the larger text
inside a commit body. This allows some code in JGit to be simplified.
Change-Id: I367e42209e805bd5e1f41b4072aeb2fa98ec9d99
A larger than expected number of real-world repositories found on
the Internet contain invalid author, committer and tagger lines
in their history. Many of these seem to be caused by users misusing
the user.name and user.email fields, e.g.:
[user]
name = Au Thor <author@example.com>
email = author@example.com
that some version of Git (or a reimplementation thereof) copied
directly into the object header. These headers are not valid and
are rejected by a strict fsck, making it impossible to transfer
the repository with JGit/EGit.
Another form is an invalid committer line with double negative for
the time zone, e.g.
committer Au Thor <a@b> 1288373970 --700
The real world is messy. :(
Allow callers and users to weaken the fsck settings to accept these
sorts of breakages if they really want to work on a repo that has
broken history. Most routines will still function fine, however
commit timestamp sorting in RevWalk may become confused by a corrupt
committer line and sort commits out of order. This is mostly fine if
the corrupted chain is shorter than the slop window.
Change-Id: I6d529542c765c131de590f4f7ef8e7c1c8cb9db9
* stable-3.7:
Prepare 3.7.2-SNAPSHOT builds
JGit v3.7.1.201504261725-r
Revert "Let ObjectWalk.markUninteresting also mark the root tree as"
Change-Id: If1b62ff695e063d797c3d13c43e488ca56f29cbe
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The Iff2de881 tried to fix missing tree ..." but introduced severe
performance degradation (>10x in some cases) when acting as server
(git push) and as client (replication). IOW cure is worse than the
disease.
This reverts commit c4797fe986.
Change-Id: I4e6056eb352d51277867f857a0cab380eca153ac
Signed-off-by: David Ostrovsky <david@ostrovsky.org>
Bug: 390833
Change-Id: I29f7b79b241929877c93ac485c677487a91bb77b
Signed-off-by: André de Oliveira <andre.oliveira@liferay.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
If a non interactive rebase is launched, stopping after a conflict
should set the repository state to RepositoryState.REBASING_MERGE
instead of RepositoryState.REBASING_INTERACTIVE.
Bug: 452623
Change-Id: Ie885aab6d71dabd158a718af0d14fff643c9b850
Also-by: Arthur Daussy <arthur.daussy@obeo.fr>
Signed-off-by: Laurent Delaigue <laurent.delaigue@obeo.fr>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
When RecursiveMerger found that there are multiple base-commits for the
commits to be merged it tries to temporarily merge the base commits. But
if these base commits have no common predecessor there was a bug in JGit
leading to a NPE. This commit fixes this by enforcing that an empty tree
is used as base when merging two unrelated base commits.
This logic was already there when merging two commits which have no
common predecessor (ThreeWayMerger.mergeBase()). But the code which was
computing a new temporary base commit in case of criss-cross merges
didn't take care to pick an empty tree when no common predecessor can be
found.
Bug: 462671
Change-Id: Ibd96302f5f81383f36d3b1e3edcbf5822147b1a4
CherryPickCommand only works on a non-bare repository, as it must
modify the working tree and index in case of a merge conflict. In
tests, being able to recover from a merge conflict is less important,
as the caller should be able to control the full contents of files in
advance of the cherry-pick.
Change-Id: Ic332e44df1308b9336e884666b08c1f6db64513d
As we moved minimum Java version to 7 we don't need a separate bundle
and feature for JGit features depending on Java 7 anymore.
Change-Id: Ib5da61b0886ddbdea65298f1e8c6d65c9879ced1
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This reverts commit 6bc48cdc62.
Until git v1.7.10.2~29^2~1 (builtin/merge.c: reduce parents early,
2012-04-17), C git merge would make merge commits with duplicate parents
when asked to with a series of commands like the following:
git checkout origin/master
git merge --no-ff origin/master
Nowadays "git merge" removes redundant parents more aggressively
(whenever one parent is an ancestor of another and not just when
duplicates exist) but merges with duplicate parents are still permitted
and can be created with git fast-import or git commit-tree and history
viewers need to be able to cope with them.
CommitBuilder is an interface analagous to commit-tree, so it should
allow duplicate parents. (That said, an option to automatically remove
redundant parents would be useful.)
Reported-by: Dave Borowitz <dborowitz@google.com>
Change-Id: Ia682238397eb1de8541802210fa875fdd50f62f0
Signed-off-by: Jonathan Nieder <jrn@google.com>
Callers may wish to use TemporaryBuffer as an essentially unbounded
buffer by passing Integer.MAX_VALUE as the size. (This makes it
behave like ByteArrayOutputStream, only without requiring contiguous
memory.) Unfortunately, it was always allocating an array in the
backing block pointer list to hold enough blocks to MAX_VALUE--all
262,016 of them. It wasn't allocating the blocks themselves, but this
array was still extremely wasteful, using about 2MiB of memory on a
64-bit system.
Tweak the interface to specify an estimated size, and only allocate
the block pointer list enough entries to hold that size. It's an
ArrayList, so if that estimate was wrong, it'll grow. We assume the
cost of finding enough contiguous memory to grow that array is
acceptable.
While we're in there, fix an off-by-one error: due to integer division
we were undercounting the number of blocks needed to store n bytes of
data as (n / SZ).
Change-Id: I794eca3ac4472bcc605b3641e177922aca92b9c0
When setting the parents of a commit with setParentIds() or
addParentId() it should be checked that we don't have duplicate parents.
An IllegalArgumentException should be thrown in this case.
Change-Id: I9fa9f31149b7732071b304bca232f037146de454
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
This includes both leaving existing Change-Ids alone (as, for example
Gerrit's commit-msg hook does) and programmatically setting a value.
Change-Id: Iaaffb0107ae27de24df1f0e95a8d628fb8ea5364
This flushed out a number of bugs in the way DfsRefUpdate, or at least
the InMemoryRepository implementation, processes symrefs. These have
been fixed, to an extent, in InMemoryRepository, but other
implementations may still suffer from these bugs.
Change-Id: Ifd12115a0060b9ff45a88d305b72f91ca0472f9a
Native git supports "git describe --long". This will enforce returning a
long description of a commit even if a tag is directly pointing to the
commit (in contrast to just returning the tag name as it is now). This
commit teaches JGits DescribeCommand and the describe command in the pgm
package to support "--long".
Bug: 460991
Change-Id: I65e179b79e89049c6deced3c71cb3ebb08ed0a8f
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This allows for testing arbitrary sets of push/fetch hooks (e.g.
PreReceiveHook) without depending on either an external protocol (e.g.
HTTP) or the local filesystem.
Change-Id: I4ba2fff9c8a484f990dea05e14b0772deddb7411
* stable-3.7:
Prepare 3.7.1-SNAPSHOT builds
JGit v3.7.0.201502260915-r
Read user.name and email from environment first
Provide more details in exceptions thrown when packfile is invalid
Change-Id: I427f861c6bc94da5e3e05dbbebbf0ad15719a323
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
According to [1] user name and email are taken first from the
environment variables:
GIT_AUTHOR_NAME, GIT_AUTHOR_EMAIL
GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL
In case (some of) these environment variables are not set, the
information is taken from the git configuration.
JGit doesn not yet support the environment variables GIT_AUTHOR_DATE and
GIT_COMMITTER_DATE.
[1] https://www.kernel.org/pub/software/scm/git/docs/git-commit-tree.html#_commit_information
Bug: 460586
Change-Id: I3ba582b4ae13674cf319652b5b13ebcbb96dd8ec
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Current ArchiveCommand design doesn't allow to pass in options to
underlying stream implementations. To overcome this, client has to
implement custom format implementation (it cannot be derived from
the existing one, because the classes are marked as final), and set
the options using ThreadLocal, before the method
ArchiveOutputStream createArchiveOutputStream(OutputStream s)
is get called.
This change extends the ArchiveCommand.Format by allowing to pass
option map during creation of ArchiveOutputStream.
ArchiveCommand is extended correspondingly. That way client can
easily pass options to the underlying streams:
Map<String, Object> level = ImmutableMap.<String, Object> of(
"level", new Integer(9));
new ArchiveCommand(repo)
.setFormat("zip")
.setFormatOptions(level)
.setTree(tree)
.setPaths(paths)
.setPrefix(prefix)
.setOutputStream(sidebandOut)
.call();
Change-Id: I1d92a1e5249117487da39d19c7593e4b812ad97a
Signed-off-by: David Ostrovsky <david@ostrovsky.org>
Since we updated minimum Java version to Java 7 the console bundle
doesn't need to be a separate bundle anymore. Move the contained classes
to the pgm bundle which is using these classes.
Change-Id: If8e6f2d7405fdfe6f4b178673b4ccf99c67d4b64
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* stable-3.7:
Add option --orphan for checkout
Prepare post 3.7.0.201502031740-rc1 builds
JGit v3.7.0.201502031740-rc1
Support for the pre-commit hook
Fix FileUtils.testRelativize_mixedCase which failed on Mac OS X
Add a hook test
Introduce hook support into the FS implementations
If a pack isn't found on disk remove it from pack list
Conflicts:
org.eclipse.jgit.java7.test/META-INF/MANIFEST.MF
Change-Id: I936acd24d47b911fa30ab29856094e1b2c6ac3db
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
HFS is case insensitive hence expecting it to return the result for case
sensitive filesystem doesn't work.
Change-Id: I292eab78e50711529a0412f9a54e174a3ac16109
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This introduces the background plumbing necessary to run git hooks from
JGit. This implementation will be OS-dependent as it aims to be
compatible with existing hooks, mostly written in Shell. It is
compatible with unix systems and windows as long as an Unix emulator
such as Cygwin is in its PATH.
Change-Id: I1f82a5205138fd8032614dd5b52aef14e02238ed
Signed-off-by: Laurent Goubet <laurent.goubet@obeo.fr>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Core classes to parse and process .gitattributes files including
support for reading attributes in WorkingTreeIterator and the
dirCacheIterator.
The implementation follows the git ignore implementation. It supports
lazy reading attributes while walking the working tree.
Bug: 342372
CQ: 9078
Change-Id: I05f3ce1861fbf9896b1bcb7816ba78af35f3ad3d
Also-by: Marc Strapetz <marc.strapetz@syntevo.com>
Also-by: Gunnar Wagenknecht <gunnar@wagenknecht.org>
Also-by: Arthur Daussy <arthur.daussy@obeo.fr>
Signed-off-by: Gunnar Wagenknecht <gunnar@wagenknecht.org>
Signed-off-by: Marc Strapetz <marc.strapetz@syntevo.com>
Signed-off-by: Arthur Daussy <arthur.daussy@obeo.fr>
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
* stable-3.6:
Prepare 3.6.2-SNAPSHOT builds
JGit v3.6.1.201501031845-r
Trim author/committer name and email in commit header
Rename detection should canonicalize line endings
PathMatcher should respect "assumeDirectory" flag
Change-Id: Idd48c6d94cf1ab09abc07f70d50890b1b78e1833
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
C Git trims name and email before inserting them into the commit header
so that " A U Thor " and " author@example.com " becomes
"A U Thor <author@example.com>" with a single separating space.
This changes PersonIdent#toExternalString() to trim name and email
before concatenating them.
Change-Id: Idd77b659d0db957626824f6632e2da38d7731625
Signed-off-by: Rüdiger Herrmann <ruediger.herrmann@gmx.de>
Native Git canonicalizes line endings when detecting
renames, more specifically it replaces CRLF by LF.
See: hash_chars in diffcore-delta.c
Bug: 449545
Change-Id: Iec2aab12ae9e67074cccb7fbd4d9defe176a0130
Signed-off-by: Marc Strapetz <marc.strapetz@syntevo.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The path matcher should not fail if the rule ends with trailing slash,
target pattern does not ends with the slash and the "assumeDirectory"
flag is set.
E.g. */bin/ should also match a/bin if this pattern is threated as
directory by WorkingTreeIterator (FileMode.TREE).
The old code/tests have never tested directory rules with patterns
*without* trailing slashes but with the "assumeDirectory" flag set.
Unfortunately this is exactly what WorkingTreeIterator does... The tests
are changed to test *both* cases now (with trailing slash and without)
if the target pattern has trailing slash (represents directory).
Bug: 454672
Change-Id: I621c1644d9e94df3eb9f6f09c6de0fe51f0950a4
Also-by: Markus Duft <markus.duft@salomon.at>
Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
* stable-3.5:
JGit v3.5.3.201412180710-r
JGit v3.4.2.201412180340-r
ObjectChecker: Disallow names potentially mapping to ".git" on HFS+
ObjectChecker: Disallow Windows shortname "GIT~1"
ObjectChecker: Disallow ".git." and ".git<space>"
Always ignore case when forbidding .git in ObjectChecker
DirCache: Refuse to read files with invalid paths
DirCache: Replace isValidPath with DirCacheCheckout.checkValidPath
Replace "a." with "a-" in unit tests
Apache HttpClientConnection: replace calls to deprecated LocalFile()
Fix two nits about DirCacheEntry constructors
Detect buffering failures while writing rebase todo file
Deprecate TemporaryBuffer.LocalFile without parent directory
Switch FileHeader.extractFileLines to TemporaryBuffer.Heap
AmazonS3: Buffer pushed pack content under $GIT_DIR
DirCache: Buffer TREE extension to $GIT_DIR
Change-Id: Iee8acbaa9d4d9047b550641db1b8845d64530785
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* stable-3.4:
JGit v3.4.2.201412180340-r
ObjectChecker: Disallow names potentially mapping to ".git" on HFS+
ObjectChecker: Disallow Windows shortname "GIT~1"
ObjectChecker: Disallow ".git." and ".git<space>"
Always ignore case when forbidding .git in ObjectChecker
DirCache: Refuse to read files with invalid paths
DirCache: Replace isValidPath with DirCacheCheckout.checkValidPath
Replace "a." with "a-" in unit tests
Apache HttpClientConnection: replace calls to deprecated LocalFile()
Fix two nits about DirCacheEntry constructors
Detect buffering failures while writing rebase todo file
Deprecate TemporaryBuffer.LocalFile without parent directory
Switch FileHeader.extractFileLines to TemporaryBuffer.Heap
AmazonS3: Buffer pushed pack content under $GIT_DIR
DirCache: Buffer TREE extension to $GIT_DIR
Change-Id: I398cf40b006a05a6537788fc6eb1f84df1ed8814
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Mac's HFS+ folds concatentations of ".git" and ignorable Unicode
characters [1] to ".git" [2]. Hence we need to disallow all names which
could potentially be a shortname for ".git". Example: in an empty
directory create a folder ".g\U+200Cit". Now you can't create another
folder ".git".
The following characters are ignorable Unicode which are ignored on
HFS+:
unicode hex name
-------------------------------------------------
U+200C 0xe2808c ZERO WIDTH NON-JOINER
U+200D 0xe2808d ZERO WIDTH JOINER
U+200E 0xe2808e LEFT-TO-RIGHT MARK
U+200F 0xe2808f RIGHT-TO-LEFT MARK
U+202A 0xe280aa LEFT-TO-RIGHT EMBEDDING
U+202B 0xe280ab RIGHT-TO-LEFT EMBEDDING
U+202C 0xe280ac POP DIRECTIONAL FORMATTING
U+202D 0xe280ad LEFT-TO-RIGHT OVERRIDE
U+202E 0xe280ae RIGHT-TO-LEFT OVERRIDE
U+206A 0xe281aa INHIBIT SYMMETRIC SWAPPING
U+206B 0xe281ab ACTIVATE SYMMETRIC SWAPPING
U+206C 0xe281ac INHIBIT ARABIC FORM SHAPING
U+206D 0xe281ad ACTIVATE ARABIC FORM SHAPING
U+206E 0xe281ae NATIONAL DIGIT SHAPES
U+206F 0xe281af NOMINAL DIGIT SHAPES
U+FEFF 0xefbbbf ZERO WIDTH NO-BREAK SPACE
[1] http://www.unicode.org/versions/Unicode7.0.0/ch05.pdf#G40025http://www.unicode.org/reports/tr31/#Layout_and_Format_Control_Characters
[2] http://dubeiko.com/development/FileSystems/HFSPLUS/tn1150.html#UnicodeSubtleties
Change-Id: Ib6a1dd090b2649bdd8ec16387c994ed29de2860d
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Windows creates shortnames for all non-8.3 files (see [1]). Hence we
need to disallow all names which could potentially be a shortname for
".git". Example: in an empty directory create a folder "GIT~1". Now you
can't create another folder ".git".
The path "GIT~1" may map to ".git" on Windows. A potential victim to
such an attack first has to initialize a git repository in order to
receive any git commits. Hence the .git folder created by init will get
the shortname "GIT~1". ".git" will only get a different shortname if the
user has created a file "GIT~1" before initialization of the git
repository.
[1] http://en.wikipedia.org/wiki/8.3_filename
Change-Id: I9978ab8f2d2951c46c1b9bbde57986d64d26b9b2
Signed-off-by: Christian Halstrick <christian.halstrick@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Windows treats "foo." and "foo " as "foo". The ".git" directory is
special, as it contains metadata for a local Git repository. Disallow
variations that Windows considers to be the same.
Change-Id: I28eb48859a95a89111b4987c91de97557e3bb539
The component name ".GIT" inside a tree entry could confuse a
case insensitive filesystem into looking at a submodule and
not a directory entry.
Disallow any case permutations of ".git" to prevent this
confusion from entering a repository and showing up at a
later date on a case insensitive system.
Change-Id: Iaa3f768931d0d5764bf07ac5f6f3ff2b1fdda01b
If the DirCache contains a path that is known to be invalid, refuse to
read the DirCache into memory. This avoids confusing errors later if
an invalid path read from the DirCache were to be passed into a new
DirCacheEntry constructor.
Change-Id: Ic033d81e23a5fbd554cc4dff80a232504562ffa8
isValidPath is an older simple form of the validation performed by
checkValidPath. Use the latter as it more consistently matches
git-core's validation rules.
By running the same validation as fsck, callers creating an entry
for the DirCache are more likely to learn early they are trying
to build trees that will fail fsck.
Change-Id: Ibf5ac116097156aa05c18e231bc65c0854932eb1
Windows does not like naming files "a.". The trailing "." may be
dropped by the filesystem, which is confusing. Even though these
tests currently do not write to disk, future tests like them might.
Replace "." with "-", which has the same sorting properties that
were desirable about ".", but does not have the same limitations.
Change-Id: Ie5b7594bf5e79828d1341883c73ddb70123d5055
When updating a submodule (e.g. during recursive clone) the repository
for the submodule should be located at <gitdir>/modules/<submodule-path>
whereas the working tree of the submodule should be located at
<working-tree>/<submodule-path> (<gitdir> and <working-tree> are
associated to the containing repository). Since CloneCommand has learned
about specifying a separate gitdir this is easy to implement in
SubmoduleUpdateCommand.
Change-Id: I9b56a3dfa50f97f6975c2bb7c97b36296f331b64
This feature is needed to support the new submodule layout where the
.git folder of the submodules is under .git/modules/<submodule>.
Change-Id: If5f13426cfd09b7677e23478e9700c8c25a6dae5
Native git's "init" command allows to specify the location of the .git
folder with the option "--separate-git-dir". This allows for example to
setup repositories with a non-standard layout. E.g. .git folder under
/repos/a.git and the worktree under /home/git/a. Both directories
contain pointers to the other side: /repos/a.git/config contains
core.worktree=/home/git/a . And /home/git/a/.git is a file containing
"gitdir: /repos/a.git". This commit adds that option to InitCommand.
This feature is needed to support the new submodule layout where the
.git folder of the submodules is under .git/modules/<submodule>.
Change-Id: I0208f643808bf8f28e2c979d6e33662607775f1f
Without explicitly closing repos we can't delete the test repositories
on windows.
Change-Id: Id5fa17bd764cbf28703c2f21639d7e969289c2d6
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
To update the file length stat we need to use the length of the
temporary file since it's not yet renamed to the target file name here.
The incorrect file length stat update was introduced in
a606dc363d.
Bug: 453962
Change-Id: I715c048227553efae6f8f6b6878c0f04f2609d9c
Also-by: Konrad Kügler <swamblumat-eclipsebugs@yahoo.de>
Also-by: Christian Halstrick <christian.halstrick@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
In case of an add/add conflict, no base stage exists. The previous
implementation would skip over the entries because the condition
expected the base stage to always exist.
Change-Id: Ie2b3685d958c09b241991b74e6177401e8a1ebc9
Signed-off-by: Robin Stocker <robin@nibor.org>
The change tries to make jgit behave more like native CLI git regarding
the negation rules. According to [1] "... prefix "!" which negates the
pattern; any matching file excluded by a previous pattern will become
included again." Negating the pattern should not automatically make the
file *not ignored* - other pattern rules have to be considered too.
The fix adds test cases for both bugs 448094 and 407475.
[1] https://www.kernel.org/pub/software/scm/git/docs/gitignore.html
Bug: 448094
Bug: 407475
Change-Id: I322954200dd3c683e3d8f4adc48506eb99e56ae1
Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Entries should only be written to the working tree managed by the
Repository. Simplify callers by passing only the entry and computing
the work tree location inside of the checkoutEntry method.
Change-Id: I574e41280d0407f1853fda12f4bd0d30f75d74e7
Encourage callers to explicitly name a directory to hold any
overflow data. Call sites have more information about what is
going into the buffer and how it should be protected at the
filesystem level than just throwing content to the system wide
temporary directory.
Callers that still really don't care (or need to care) can pass
null for the File argument to have the system directory used.
Change-Id: I89009bbee49d3850d42cd82c2c462e51043acda0
Increase the in-memory buffer for the TREE extension to 5 MiB, and
overflow to $GIT_DIR instead of /tmp. Using a larger buffer reduces
the chances a repository will overflow and need to spool the extension
to disk. Using $GIT_DIR allows the TREE extension contents to have
the same file system protections as the final $GIT_DIR/index.
Wrap the entire thing in a try/finally to ensure the temp file is
deleted from disk after the block has finished using it. To avoid
dangling NFS files, LocalFile.destroy() does close the local file
before deleting it.
Change-Id: I8f871181a4689e3ebf0cdd4fd1769333cf7546c3
Callers should manage the ObjectReader, as this allows the JGit library to cache
context relevant information across files checked out at the same time. If the
caller only has one file to checkout, it should still explicitly manage the life
span of the ObjectReader.
Change-Id: Ib57fba6cb4b774ccff8c416ef4d32e2b390f16a9
To improve ignore parser performance we can avoid using java.util.regex
code on simple wildcard patterns with leading or trailing asterisk. As
those patterns represent a majority of ignore rules, the index diff
performance can be drastically increased on huge repository with lot of
ignore rules.
Bug: 450466
Change-Id: I80428441cc8d5de5468813f841d89322413eed8b
Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Actually the test only allows a range from [1,255], so let's name the
variable so.
Change-Id: Iecdb8149b83389c67e3cd2f64f4a654c175475be
Signed-off-by: Stefan Beller <sbeller@google.com>
JGit style is to import exactly the classes required, and never
to use "import foo.*" as the foo package could add new classes
in the future which are conflicting/confusing with the imports
already used by a source file.
Change-Id: I5693408c777e5843ec65fff1163d5d717849fa34
The latest changes to IndexDiff just assumed that all configured
submodules are allways cloned. If a configured submodule did not exist
an exception was thrown. This is fixed by this commit.
Bug: 450567
Change-Id: Iabe3b196d998c19483082e5720038ebddaeb1890
In a situation where a certain path was ignored but a working tree file
with this path existed jgit didn't allow to checkout a branch which
didn't ignore this path but contained different content. JGit considered
this to be a checkout conflict to prevent overwriting the file in the
working tree and raised an error. This commit fixes this by ensuring
that ignored dirty working tree files don't lead to a checkout conflict.
Bug: 450169
Change-Id: I90288d314ffac73c24a9c70a5181f8243bd4679a
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
For each submodule native git allows to configure which modifications to
submodules should be ignored by the status command. It is possible to
ignore "none", "all", "dirty", "untracked" [1]. This configuration is
now supported by IndexDiff. The StatusCommand offers the possibility to
specify this mode.
[1] http://git-scm.com/docs/gitmodules
Change-Id: Ifd81d574a680f9b4152945ba70f8ec4af4f452c9
The current IgnoreRule/FileNameMatcher implementation scales not well
with huge repositories - it is both slow and memory expensive while
parsing glob expressions (bug 440732). Addtitionally, the "double star"
pattern (/**/) is not understood by the old parser (bug 416348).
The proposed implementation is a complete clean room rewrite of the
gitignore parser, aiming to add missing double star pattern support and
improve the performance and memory consumption.
The glob expressions from .gitignore rules are converted to Java regular
expressions (java.util.regex.Pattern). java.util.regex.Pattern code can
evaluate expression from gitignore rules considerable faster (and with
less memory consumption) as the old FileNameMatcher implementation.
CQ: 8828
Bug: 416348
Bug: 440732
Change-Id: Ibefb930381f2f16eddb9947e592752f8ae2b76e1
Signed-off-by: Andrey Loskutov <loskutov@gmx.de>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
ResetCommand threw an NPE if neither mode nor path was defined. Instead
it should default to a mixed reset like native git does.
Change-Id: I455902394f9e7b0c7afae42381f34838f7f2a138
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
* stable-3.5:
Prepare 3.5.1-SNAPSHOT builds
JGit v3.5.0.201409260305-r
Fix PackWriterBitmapWalker handling non-existing uninteresting objects
Enable maven site generation for jgit
Generate javadocs as part of Maven site project reports
Compare API changes with clirr against 3.4.1
[cli] Use chaining credentials provider to enable .netrc
Add chaining credentials provider
[Java 8] Configure doclint to accept missing descriptions
Do not use .netrc implicitly if no CredentialsProvider was set
Prepare post 3.5.0-rc1 builds
JGit 3.5.0.201409071800-rc1
Fix the ls-remote command when there is no local repo
Change-Id: Iaa4485cac6ff9c7917380e89e12e416e0f52a557
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
When writing new packs it should be allowed to specify objects as "have"
(objects which should not be included in the pack) which do not exist in
the local repository.
This works with the traditional PackWriter, but when PackWriter was
working on a repository with bitmap indexes and used
PackWriterBitmapWalker then this feature was broken. Non-existing "have"
objects lead to MissingObjectExceptions. That broke push and Gerrit
replication. When the replication target had branches unknown to the
replication source then the source repository wanted to build pack files
where "have" included branch-tips which were unknown in the source
repository.
Bug: 427107
Change-Id: I6b6598a1ec49af68aa77ea6f1f06e827982ea4ac
Also-by: Matthias Sohn <matthias.sohn@sap.com>
JGit should offer the possibility to do a garbage collection in
"aggressive" mode. In this mode garbage collection more aggressively
optimize the repository at the expense of taking much more time.
Technically a aggressive mode garbage collection differs from a
non-aggressive one by:
- not reusing packed objects found in old packs. Recompress every object
- the configuration pack.window is set to 250 (the default is 10)
- the configuration pack.depths is set to 250 (the default is 50)
The associated classes in org.eclipse.jgit.api and the command line
command in org.eclipse.jgit.pgm expose this new option.
The configuration parameters gc.aggressiveDepth and gc.aggressiveWindow
have been introduced to configure this feature.
Bug: 444332
Change-Id: I024101f2810acf6be13ce144c9893d98f5c4ae76
Set the commit message to be used for the merge commit (in case one is
created)
Bug: 442886
Change-Id: Ie5ecc13822faa366f00b3daa07f74c8441cae195
Signed-off-by: Axel Richard <axel.richard@obeo.fr>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
uninteresting
Using the ObjectWalk and marking a commit as uninteresting didn't mark
its root tree as uninteresting. This caused the "missing tree ..."
error in Gerrit under special circumstances. For example, if the
patch-set 2 changes only the commit message then the patch-set 1
and patch-set 2 share the same root-tree:
ps1 -> o o <- ps2
\ /
o root-tree
The transported pack will contain the ps2 commit but not the root-tree
object.
When using the BaseReceivePack.setCheckReferencedObjectsAreReachable
JGit will check the reachability of all referenced objects not provided
in the transported pack. Since the ps1 was advertised it will properly
be marked as uninteresting. However, the root-tree was reachable because
the ObjectWalk.markUninteresting missed to mark it as uninteresting.
JGit was then rejecting the pack with the "missing tree ..." exception.
Gerrit-issue: https://code.google.com/p/gerrit/issues/detail?id=1582
Change-Id: Iff2de8810f14ca304e6655fc8debeb8f3e20712b
Signed-off-by: Saša Živkov <sasa.zivkov@sap.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
This matches what C Git does, see "stripped" in `man git-commit-tree`.
It also fixes the bug of the user where an user.email like "<>" would
show up as "<<>>" in EGit.
Bug: 439844
Change-Id: I567a3c620e191ce9d37d318417e63cb5d4483419
Signed-off-by: Robin Stocker <robin@nibor.org>
This reverts commit b646578d89.
openInputStream() is never used in JGit, nor is it used by any
known working DFS implementation. The method was added as a
utility for reading back from a DfsInserter, but the final
implementation of that feature does not requrire this method.
Change-Id: I075ad95e40af49c92b554480f8993ef5658f7684
In the DFS implementation, flushing an inserter writes a new pack to
the storage system and is potentially very slow, but was the only way
to ensure previously-inserted objects were available. For some tasks,
like performing a series of three-way merges, the total size of all
inserted objects may be small enough to avoid flushing the in-memory
buffered data.
DfsOutputStream already provides a read method to read back from the
not-yet-flushed data, so use this to provide an ObjectReader in the
DFS case.
In the file-backed case, objects are written out loosely on the fly,
so the implementation can just return the existing WindowCursor.
Change-Id: I454fdfb88f4d215e31b7da2b2a069853b197b3dd
Instead of passing on the start point as is to CreateBranchCommand, the
resolved ObjectId was used. Given this, CreateBranchCommand did not set
up tracking.
This also fixes CreateBranchCommand with setStartPoint(null) to use HEAD
(instead of NPEing), as documented in the Javadoc.
Bug: 441153
Change-Id: I5ed82b4a4b4a32a81a7fa2854636b921bcb3d471
Signed-off-by: Robin Stocker <robin@nibor.org>
JGit handled this case improperly which these tests demonstrate. Fixed
by I25915880f304090fe90584c79bddf021231227a2.
Bug: 440537
Change-Id: Ia29c1d6cf8c0ce724cc3ff5ed9e0b396949b44bf
Signed-off-by: Laurent Goubet <laurent.goubet@obeo.fr>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
If the IndexDiffFilter is asked whether it should include or filter out
a certain path and for that path there is a dircache entry with a stage
different from 0, then the filter should never filter out this entry.
IndexDiffFilter is an optimized version of AnyDiffFilter and there is no
case where the index contains non-0 stages but we still don't see any
diff for that path.
Change-Id: I25915880f304090fe90584c79bddf021231227a2
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The fix is to move the new head commit to the newly-created revert
commit, so that additional revert commits will use the correct head.
Change-Id: I5de3a9a2a4c276e60af732e9c507cbbdfd1a4652
Signed-off-by: Maik Schreiber <blizzy@blizzy.de>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Apparently repo allows projects overlapping, e.g. one project's path is "foo"
and another project's path is "foo/bar". This is not supported in git submodule.
At JGit repo side we'll skip all the submodules that are in subdirectories of
other submodules, and on repo side we'll make them submodules to resolve this
problem.
Change-Id: I6820c4ef400c530a36150b1228706adfcc43ef64
Signed-off-by: Yuxuan 'fishy' Wang <fishywang@google.com>
Previously when RecursiveMerger was trying to create a single virtual
common base for the merge it was failing when this lead to content-merge
conflicts. This is different from what native git is doing. When native
git's recursive merge algorithm creates a new common base it will merge
the multiple parents and simply take the merge result (potentially
including conflict markers) as common base. See my discussion with Shawn
here: http://www.spinics.net/lists/git/msg234959.html :
> - How should workingtree, index (stage1,2,3) look like if during
that
> merge of common ancestors a conflict occurs? Will I see in stage2
and
> stage3 really see content of X1 and X2?
Its done entirely in memory and never touches the working tree or
index. When a conflict exists in the X1-X2 merge the conflict is
preserved into the new virtual base.
There is still the possibility that the merge of parents lead to
conflicts. File/Folder conclicts, conflicts on filemodes. This commit
only fixes the situation for conflicts when merging content.
Bug: 438203
Change-Id: If45bc3d078b3d3de87b758e71d7379059d709603
When RecursiveMerger tried to determine a common base tree it was
recursively tried to merge multiple common bases. But these intermediate
merges which have just been done to determine a single common base for
the final merge already filled some important fields (toBeCheckedOut,
toBeDeleted, ...). These side effects of the intermediate merges led to
wrong results of the final merge. One symptom was that after a recursive
merge which should be succesful you could still see leftover files in
the worktree: files which existed in the (virtual) common base but which
don't exist anymore in the branches to be merged.
The solution is easy: Clear the appropriate fields after common base
determination and start the final merge with a clean state.
Change-Id: I644ea9e1cb15360f7901bc0483cdb9286308c226
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
As described in native gits file "git-read-tree.txt" git has in a
special mode when doing the "initial" checkout. "Initial" means that the
index is empty before the checkout. This was not handled correctly in
JGit and is fixed in this commit. Also see
https://github.com/git/git/blob/master/Documentation/git-read-tree.txt#L181
Change-Id: I9b9d1bd9ebf349cfca420c891c7b099a18d07ba4
Setting branch.<name>.rebase or pull.rebase to 'preserve' will preserve
merges during rebase. Also, pull.rebase is now consulted if there is no
branch-specific configuration.
Bug: 429664
Change-Id: I345fa295c7e774e0d0a8e6aba30fbfc3552e0084
Signed-off-by: Konrad Kügler <swamblumat-eclipsebugs@yahoo.de>
With --preserve-merges C Git re-does merges using the rewritten merge
parents, discarding the old merge commit. For the common use-case of
pull with rebase this is unfortunate, as it loses the merge conflict
resolution (and other fixes in the merge), which may have taken quite
some time to get right in the first place.
To overcome this we use a two-fold approach:
If any of the (non-first) merge parents of a merge were rewritten, we
also redo the merge, to include the (potential) new changes in those
commits.
If only the first parent was rewritten, i.e. we are merging a branch
that is otherwise unaffected by the rebase, we instead cherry-pick the
merge commit at hand. This is done with the --mainline 1 and --no-commit
options to apply the changes introduced by the merge. Then we set up an
appropriate MERGE_HEAD and commit the result, thus effectively forging a
merge.
Apart from the approach taken to rebase merge commits, this
implementation closely follows C Git. As a result, both Git
implementations can continue rebases of each other.
Preserving merges works for both interactive and non-interactive rebase,
but as in C Git it is easy do get undesired outcomes with interactive
rebase.
CommitCommand supports committing merges during rebase now.
Bug: 439421
Change-Id: I4cf69b9d4ec6109d130ab8e3f42fcbdac25a13b2
Signed-off-by: Konrad Kügler <swamblumat-eclipsebugs@yahoo.de>
DiffFormatter now suports either side being null and the log program
will output the diff for the first commit.
Bug: 395791
Change-Id: I378957b57e9ad1f7195ba416f402178453f0ebd3
Making the methods static would gain little in performance,
make the code harder to change. Removing unncessary warnings
is more important.
Change-Id: If3e6aa9c1d92e58b4e7a8e246cf4aace237d7a7b
These settings were added by Eclipse simply by touching
the project settings. Adding these makes it simpler to see
what local changes have been made.
Change-Id: Iab0aa62530312eb0c78b03b5c6a632742bcc4978
* stable-3.4:
Prepare 3.4.2-SNAPSHOT builds
JGit v3.4.1.201406201815-r
Allow retrying connecting SshSession in case of an exception
Change-Id: I7efb009b9e012637a16c57e2e93e074023b8e46c
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Connecting to an SshSession may fail due to different reasons. Jsch for
example often throws an com.jcraft.jsch.JschException: verify: false.[1]
The issue is still not fixed in JSch 0.1.51.
In such a case it is worth retrying to connect. The number of connection
attempts can be configured using ssh_config parameter
"ConnectionAttempts" [2].
Don't retry if the user canceled authentication.
[1] http://sourceforge.net/p/jsch/bugs/58/
[2] http://linux.die.net/man/5/ssh_config
Bug: 437656
Change-Id: I6dd2a3786b7d3f15f5a46821d8edac987a57e381
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The current behavior of passing a TreeFilter to RevWalk has limited
usefulness, since the RevFilter derived from the TreeFilter is always
ANDed together with any other RevFilters. It is also tied fairly
tightly to the parent rewriting mechanism.
Make TreeRevFilter a generic RevFilter that matches modified paths
against any TreeFilter. This allows for more complex logic like
(modified this path OR authored by this person).
Leave the rewrite flag logic in this class, since it's closely tied to
the parent comparison code, but hidden behind a protected constructor.
Change-Id: Ia72ef591a99415e6f340c5f64583a49c91f1b82f
When update the manifest against a bare repository, RepoCommand will replace
every existing content from the repository with contents populated from the
manifest. Added note for that and a unit test to make sure this behavior.
Change-Id: I1d5960e84bca5aa2a4e86f424d2ddd4197894cdc
Signed-off-by: Yuxuan 'fishy' Wang <fishywang@google.com>
PackFileTest lives in o.e.j.internal.storage.file, so I think it's OK for
it to acknowledge the existence of FileRepository in order to avoid some
unnecessary casting, and probably nicer to avoid the repetition too.
Change-Id: I0de592a32f6178e6d6bf114848101e185b3111a1
Signed-off-by: Roberto Tyley <roberto.tyley@gmail.com>
Unstashed changes are saved in a commit which is added as an additional
parent to the stash commit.
This behaviour is fully compatible with C Git stashing of untracked
files.
Bug: 434411
Change-Id: I2af784deb0c2320bb57bc4fd472a8daad8674e7d
Signed-off-by: Andreas Hermann <a.v.hermann@gmail.com>
If a client passes a multiline message as argument to ReflogWriter.log()
the Reflog gets corrupted and cannot be parsed. ReflogWriter.log() is
invoked implicitly from various commands such as StashCreate, Rebase and
many more. However the message is not always filtered for line feeds.
Such an example is the StashCreateOperation of EGit which passes
unchecked user input as commit message. If a multiline comment is pasted
to the stash create dialog, the reflog gets corrupted.
ReflogWriter now replaces line endings in log message with spaces.
Bug: 435509
Change-Id: I3010cc902e13bee4d7b6696dfd11ab51062739d3
Signed-off-by: Andreas Hermann <a.v.hermann@gmail.com>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The aim of this change is to place all commits of a branch on the same
lane and commits of other (side) branches on different lanes.
The algorithm treats first parents of a commit specially by placing them
on the same lane as the commit itself. When a commit is the first parent
of multiple children it could be placed on any of these children's
lanes. In this case it is placed on the longest child lane, as this is
usually the lane of the branch the commit actually was made on.
Other (non-first) parents are placed on new lanes. This creates a layout
that should make it easier to see branches and merges and follow linear
branch histories.
This differs from the previous approach, which sometimes plotted the
commits of a side branch on the same lane as the base branch commits and
further commits on the base branch appeared on a different lane.
This made the base branch appear as if it was the side branch and
the side branch appears to be the base branch.
In addition to lane assignment, also the plotting code changed to start
drawing a branch lane from the commit where it forks out. Previously it
started only when the first commit on the branch appeared.
Active lanes are continued with every commit that is processed.
Previously lanes were only continued when the next commit on the lane
was encountered. This could produce (temporarily) dangling commits if
the next commit on the lane was not processed yet.
CQ: 8299
Bug: 419359
Bug: 434945
Change-Id: Ibe547aa24b5948ae264f7d0f56a492a4ef335608
Signed-off-by: Konrad Kügler <swamblumat-eclipsebugs@yahoo.de>
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Adds support for Negotiate(SPNEGO) HTTP authentication method. This method
is set to have a higher priority as Digest HTTP authentication method.
Bug: 428836
Change-Id: Ib181096d39f538df1dd7d3f36516843777bf12ae
Signed-off-by: Laurent Goujon <lgoujon@twitter.com>
Signed-off-by: Chris Aniszczyk <caniszczyk@gmail.com>
Terry Parker