summaryrefslogtreecommitdiffstats
path: root/org.eclipse.jgit.packaging/org.eclipse.jgit.source.feature/.gitignore
diff options
context:
space:
mode:
authorDave Borowitz <dborowitz@google.com>2015-06-29 18:05:11 -0700
committerDave Borowitz <dborowitz@google.com>2015-07-10 13:16:37 -0700
commitd5a71e9ca3d95330acdd858306c4f75ae0b01e58 (patch)
treeac0290a03ee6fa398644ffa08236df5db1dfa3fe /org.eclipse.jgit.packaging/org.eclipse.jgit.source.feature/.gitignore
parent217b2a7cc5366491be5317d20f3f3c1b6e3475bf (diff)
downloadjgit-d5a71e9ca3d95330acdd858306c4f75ae0b01e58.tar.gz
jgit-d5a71e9ca3d95330acdd858306c4f75ae0b01e58.zip
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] https://github.com/sitaramc/gitolite/blob/cf062b8bb6b21a52f7c5002d33fbc950762c1aa7/contrib/hooks/repo-specific/save-push-signatures Change-Id: Id3eb32416f969fba4b5e4d9c4b47053c564b0ccd
Diffstat (limited to 'org.eclipse.jgit.packaging/org.eclipse.jgit.source.feature/.gitignore')
0 files changed, 0 insertions, 0 deletions