Skip to content

Include git-hook regeneration in restore documentation #8181

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

Merged
merged 4 commits into from
Sep 15, 2019
Merged

Include git-hook regeneration in restore documentation #8181

merged 4 commits into from
Sep 15, 2019

Conversation

wranders
Copy link
Contributor

This PR is to include the git-hook regeneration command to the restore section of the Backup and Restore guide.

When migrating to a different installation method (eg. binary -> Docker), there is currently no mention of needing to regenerate git-hooks, causing push actions to fail on the new installation.

@codecov-io
Copy link

codecov-io commented Sep 14, 2019

Codecov Report

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

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #8181      +/-   ##
==========================================
+ Coverage   41.83%   41.84%   +<.01%     
==========================================
  Files         482      482              
  Lines       64613    64613              
==========================================
+ Hits        27033    27035       +2     
+ Misses      34109    34107       -2     
  Partials     3471     3471
Impacted Files Coverage Δ
modules/log/event.go 65.64% <0%> (+1.02%) ⬆️

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 7a8e299...e73268a. Read the comment docs.

@GiteaBot GiteaBot added the lgtm/need 2 This PR needs two approvals by maintainers to be considered for merging. label Sep 14, 2019
@wranders
Copy link
Contributor Author

Suggestions added.

Using may in the consequence language was to cover the possibility that paths could be valid in a migration, but there's no harm in running the command in that case.

@guillep2k
Copy link
Member

Suggestions added.

Using may in the consequence language was to cover the possibility that paths could be valid in a migration, but there's no harm in running the command in that case.

Of course you're right, but in a migration guide I think it's better to play safe for the reasons you mention.

@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 Sep 15, 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 Sep 15, 2019
@lunny lunny added the type/docs This PR mainly updates/creates documentation label Sep 15, 2019
@lunny lunny merged commit 8b54b58 into go-gitea:master Sep 15, 2019
@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/docs This PR mainly updates/creates documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants