For examples, I've just sent a bunch of PRs, which can be seen here : https://github.com/SlackBuildsOrg/slackbuilds/pulls Most are just one package update. Some are batches, like for the new PyPy version, there are 4 packages (pypy, pypy3, PyPy and PyPy3), therefore 4 commits, one for each package. I could have sent 4 PRs, but I want them to be either all updated at the same time, or none of them.
As a side note about batch updates : if one package in the batch has a problem, it's not very easy to just update that one inside the batch, and admins will block the whole batch. You need either to push new commits, but there'll be unuseful ones inside the batch, or you have to do some medium-advanced git-jutsu to change one commit in the lot, or even restart your commit/push from the beginning. With separate PRs, everything that works is put out of the way, and there remains only the problems to be handled. Of course, usually there are no problems, but they happen from time to time... I am taking a chance with my buildbot update : 5 packages, 3 for buildbot itself, that should all be at the same version, and two from REQUIRES. But I could have (and maybe should have) separated the requirements from the buildbot ones : if, let's say, python3-klein has a problem, I won't have my buildbot update, even though it would have worked fine with the actual non-updated python3-klein. - Yth. > Great explanation. Thank you. > > Maybe is should be in the site FAQ :-) > > > On 09/01/24 17:24, Jeremy Hansen wrote: > > > > > > On Tue, Jan 9, 2024, 9:26 AM Petar Petrov <slackal...@gmail.com> wrote: > > > > >And then on github I simply make a pull request > > how do you "simply make a pull request"? > > > > -p > > > > > > I'm a relative git and GitHub newb, but here's what I did to start > > working with GitHub. (For those who are far more knowledgeable than > > me, if there are improvements to be made, please let me know.) I'm > > sure GitLab is similar, but they have slight variations in terminology. > > > > This is aimed at other git/GitHub newbs... if you aren't one, I apologize. > > > > To get started, do the following: > > > > 1. Fork SBo's GitHub repo through the GitHub interface (you need to > > have a GitHub account and be logged into it to fork). > > 2. Clone your newly forked repo onto your computer. > > git clone $your_new_repo_address > > 3. Set SBo's GitHub as upstream to make getting public updates easier. > > git remote add upstream > > git://github.com/SlackBuildsOrg/slackbuilds.git > > <http://github.com/SlackBuildsOrg/slackbuilds.git> > > > > If you've never used git on your computer to make commits before, > > you'll need to tell git who you are so it can know who to attribute > > your commits to: > > > > git config --global user.email "y...@example.com" > > git config --global user.name <http://user.name> "Your Name" > > > > Now you're ready to start updating on your local computer. > > > > 1. Create a new branch for the package you're updating and switch to > > that branch. Typically this will be the package name that you're > > updating, but naming schemes are more for you than anything. The name > > of the branch won't affect the SBo admins reviewing your pull request. > > git checkout -B $branch_name > > 2. Make the changes to the files and verify everything works. This may > > require moving those files to a clean VM to verify they build properly > > in a clean environment. > > 3. Commit those changes to that branch on your local repo: > > git commit -m "network/discord: Update version to 1.2.3" > > location/to/changes > > (If there are multiple package changes due to dependency bumps or > > similar, do an individual commit for each package.) > > 4. Once all commits are complete that apply to your update, push those > > commits to your GitHub repo, forcing GitHub to create a new remote > > branch (since it only exists locally): > > git push -f origin $branch_name > > 5. Git will provide a link in the output you can visit to submit the > > pull request (PR) or you can just browse to your GitHub repo and you > > can submit the PR yourself (if the push was recent, it'll list the > > option at the top of the nation page, otherwise you can go into the > > branches area and can submit it that way. > > 6. Explain your changes, if necessary, when submitting the PR back to > > SBo's repo. > > > > Then it's just a matter of waiting for SBo admins to review your > > submission. If changes are needed, they'll suggest them. Once the > > changes are accepted, you can delete the branch on your repo online > > and on your local repo: > > git checkout master # first make sure you're on your master branch > > git branch -D $branch_name > > > > Once a public update is released, you can then update your local copy > > on the master branch using: > > git checkout master > > git pull upstream master > > > > From here, you can then create a new branch again to make more > > changes, commit them, push them back to GitHub, and submit a new PR. > > > > Always commit changes into a separate branch. If you commit changes to > > master, it'll give you problems when trying to sync with upstream > > after public updates. > > > > Hopefully this all makes sense. If there are any suggestions others > > have that might improve this, feel free to add them. > > > > Jeremy > > > > > > _______________________________________________ > > SlackBuilds-users mailing list > > SlackBuilds-users@slackbuilds.org > > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > > Archives -https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > > FAQ -https://slackbuilds.org/faq/ > > _______________________________________________ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/