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
CONTRIBUTING.md: Improve backport instructions #85727
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
seems good
@davidak No where does this mention that someone could be backporting multiple commits. |
is that encouraged?
it could be hard to remove one controversial commit from the PR later
Am 22. April 2020 01:11:01 MESZ schrieb worldofpeace <notifications@github.com>:
…
@davidak No where does this mention that someone could be backporting
multiple commits.
So maybe `commit` -> `commit/s`?
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#85727 (comment)
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
|
I am not sure whether we should describe how to use Not saying it's not correct, but keep it in mind when writing instructions. |
I am not sure whether we should describe how to use `git`. While I can understand having a full set of instructions can be helpful to newcomers that are also somewhat unfamiliar with `git`, people use `git` differently. For example, I typically work with a detached HEAD, and push to `refs/heads/<somebranch>` without creating a local branch first.
I guess there are at least two audiences.
One is about people who either never looked into details of how to use git, or did look but did not like what they can see there. If you want us to produce any kind of consistency with git, give us a specific recommended workflow. Otherwise it might turn out we never care about some small thing and this thing is annoying to someone.
There are of course people who do have a preference about git workflows, but such people are much more likely to know whether a workflow produces indistinguishable PRs.
Do you mean that the current description is too strongly worded and thus might be uncomfortable to some people in the second group, or do you mean that there are contributors not matching either of descriptions?
|
What you write depends on which assumptions you make about the reader. If we take your first group, and elaborate the instructions further (copy-paste quality), then one is going to have to consider more details such as the remote. How did they clone the repo? From a Nixpkgs GitHub fork or not? By not writing about how to branch/push we can avoid having to go there. |
Looking at the entire instruction and the manual — at least in a way that pushes go to the fork. I agree we are not aiming at copy-paste quality here (at least not yet), and maybe a more realistic goal is to aim at unambiguity where enough is said to be sure one is doing what is expected (or to be unsure what exactly to do and go ask…) |
yes, that was my goal. currently the instructions in the README and Manual produce different results and even tho i work every day with git, i use cherry-pick just for backporting in nixpkgs which i don't do that often. so i just followed the instructions and committed to my local release-20.03. the branch is wasted now :( the proposed change would help here. we don't really need the is it encouraged to backport multiple commits in a PR? for example 20 package updates? or 6 changes to NixOS modules that fix problems? or only with small fixes? |
396b211
to
bf9c773
Compare
I updated the commit policy to reflect the current practice in #86026 and updated the backport instructions accordingly. |
Came up in #85723 (comment).