Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ignore non-standard refs in git push #6758

Merged
merged 6 commits into from
May 14, 2019

Conversation

jeblair
Copy link
Contributor

@jeblair jeblair commented Apr 25, 2019

When replicating to gitea from a remote system which makes use of
git refs to store extra data (for example, gerrit), pushing a lot
of refs to gitea can cause problems due to the extra processing
that the pre and post receive hooks perform. But it's still
useful for gitea to be able to serve those refs. This change
skips unecessary processing of refs other than branches or tags.

We don't need to check any ref that isn't a branch for branch
protection (protection will never be enabled). So in the
pre-receive hook, we wrap that check in a test for whether the
ref is a branch.

We also don't need to add information to the activity stream about
pushes to non-standard refs, so we skip that step in the
post-receive hook for refs which are not branches or tags.

For some concrete examples, gerrit maintains a ref for every
patchset of every change in the form refs/changes/XX/YYYY/Z.
Many systems use refs/notes to store additonal data about commits.
This change allows these and other schemes to be used without
affecting gitea.

When replicating to gitea from a remote system which makes use of
git refs to store extra data (for example, gerrit), pushing a lot
of refs to gitea can cause problems due to the extra processing
that the pre and post receive hooks perform.  But it's still
useful for gitea to be able to serve those refs.  This change
skips unecessary processing of refs other than branches or tags.

We don't need to check any ref that isn't a branch for branch
protection (protection will never be enabled).  So in the
pre-receive hook, we wrap that check in a test for whether the
ref is a branch.

We also don't need to add information to the activity stream about
pushes to non-standard refs, so we skip that step in the
post-receive hook for refs which are not branches or tags.

For some concrete examples, gerrit maintains a ref for every
patchset of every change in the form refs/changes/XX/YYYY/Z.
Many systems use refs/notes to store additonal data about commits.
This change allows these and other schemes to be used without
affecting gitea.
@codecov-io
Copy link

codecov-io commented Apr 25, 2019

Codecov Report

Merging #6758 into master will decrease coverage by <.01%.
The diff coverage is n/a.

Impacted file tree graph

@@            Coverage Diff            @@
##           master   #6758      +/-   ##
=========================================
- Coverage   41.41%   41.4%   -0.01%     
=========================================
  Files         441     441              
  Lines       59729   59729              
=========================================
- Hits        24735   24732       -3     
- Misses      31755   31760       +5     
+ Partials     3239    3237       -2
Impacted Files Coverage Δ
models/unit.go 62.16% <0%> (-5.41%) ⬇️
modules/log/colors_router.go 83.33% <0%> (-4.17%) ⬇️
models/repo_list.go 66.84% <0%> (-1.06%) ⬇️
routers/repo/view.go 42.02% <0%> (-1.02%) ⬇️
modules/log/event.go 65.98% <0%> (+1.52%) ⬆️
modules/process/manager.go 81.15% <0%> (+4.34%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 24a536d...4e69688. Read the comment docs.

@GiteaBot GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Apr 25, 2019
@lunny lunny added the type/enhancement An improvement of existing functionality label Apr 25, 2019
@lafriks lafriks added this to the 1.9.0 milestone Apr 25, 2019
@openstackadmin
Copy link

👍

@GiteaBot GiteaBot added lgtm/need 1 This PR needs approval from one additional maintainer to be merged. and removed lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. labels May 12, 2019
@GiteaBot GiteaBot added lgtm/done This PR has enough approvals to get merged. There are no important open reservations anymore. and removed lgtm/need 1 This PR needs approval from one additional maintainer to be merged. labels May 13, 2019
@techknowlogick techknowlogick merged commit 488d346 into go-gitea:master May 14, 2019
jeffliu27 pushed a commit to jeffliu27/gitea that referenced this pull request Jul 18, 2019
When replicating to gitea from a remote system which makes use of
git refs to store extra data (for example, gerrit), pushing a lot
of refs to gitea can cause problems due to the extra processing
that the pre and post receive hooks perform.  But it's still
useful for gitea to be able to serve those refs.  This change
skips unecessary processing of refs other than branches or tags.

We don't need to check any ref that isn't a branch for branch
protection (protection will never be enabled).  So in the
pre-receive hook, we wrap that check in a test for whether the
ref is a branch.

We also don't need to add information to the activity stream about
pushes to non-standard refs, so we skip that step in the
post-receive hook for refs which are not branches or tags.

For some concrete examples, gerrit maintains a ref for every
patchset of every change in the form refs/changes/XX/YYYY/Z.
Many systems use refs/notes to store additonal data about commits.
This change allows these and other schemes to be used without
affecting gitea.
@go-gitea go-gitea locked and limited conversation to collaborators Nov 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
lgtm/done This PR has enough approvals to get merged. There are no important open reservations anymore. type/enhancement An improvement of existing functionality
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants