mirrors/jgit - jgit - source @ dussan.org

Tree: 45e9e28ad9

Author	SHA1	Message	Date
Dave Borowitz	45e9e28ad9	PushCertificateStore: Don't add no-op command to batch 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	8 years ago
Dave Borowitz	d7377877e0	PushCertificateStore: Return boolean from batch save methods Change-Id: I9730cb4f60c60ee6d5a7a156a0b6a53f79309ec3	9 years ago
Dave Borowitz	5706c8e38e	Allow saving push certs on a subset of refs 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	9 years ago
Dave Borowitz	f946ed1d97	PushCertificateStore: Add method to save in batch Change-Id: I8bfaee1a52d368ffe2cd7e8af1754a5261569078	9 years ago
Dave Borowitz	d5a71e9ca3	Store push certificates in refs/meta/push-certs 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	9 years ago

5 Commits (45e9e28ad9daad3c64a16685bd9c07ed18d2ab50)