Talk:Creating GitHub Pull Requests
Before creating a discussion or leaving a comment, please read about using talk pages. To create a new discussion, click here. Comments on an existing discussion should be signed using
~~~~
:
A comment [[User:Larry|Larry]] 13:52, 13 May 2024 (UTC) : A reply [[User:Sally|Sally]] 21:22, 3 November 2024 (UTC) :: Your reply ~~~~
git+ssh://
Some link for an explanation (maybe in a subarticle) about authenticity of host would be nice:
user $
git clone -o upstream git+ssh://git@git.gentoo.org/repo/gentoo.git
Cloning into 'gentoo'... The authenticity of host 'git.gentoo.org (148.251.78.52)' can't be established. ECDSA key fingerprint is SHA256:lDtZUg9Kg55tWetA0Yf+eWAZdq/SvKPIgs65EPQ98ao. Are you sure you want to continue connecting (yes/no)? y Please type 'yes' or 'no': yes Warning: Permanently added 'git.gentoo.org,148.251.78.52' (ECDSA) to the list of known hosts. Authentication failed. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.
--Charles17 (talk) 09:06, 2 December 2017 (UTC)
- According to this forum topic, the git+ssh:// protocol can be used only by Gentoo developers, not by end users. --Charles17 (talk) 17:02, 4 December 2017 (UTC)
- Yes and no. This picture explains it better. Only the developer with write access to the tree writes to git.gentoo.org. The user may do what he/she wants on the github fork. File:Github_pull_request.png Please comment on the new picture. We can improve it and then cut it into sections for this article. I think it fits better than the current illustration. --Jonas Stein (talk) 23:40, 13 December 2017 (UTC)
- Thanks for the nice picture. My question was related to this version where you said User configures the local repository using that certain command. git clone -o upstream git+ssh://git@git.gentoo.org/repo/gentoo.git. Did you mean to say ordinary users could use git+ssh://github.com but not git+ssh://git.gentoo.org?--Charles17 (talk) 07:08, 14 December 2017 (UTC)
github as main portage tree
Tip: To get this fixed sooner, use {{Proposal}}.
Step 0 variant b doesn't actually lead to a working main portage tree since it lacks metadata, e.g. eix considers the repo to be empty then. Maybe there's some more steps needed to make this work? But as-is this is leads to a flawed setup that is not fully functional. If this is not working reliably, it might be better to just recommend using two repositories. Could people comment? qgp (talk) 15:42, 13 September 2018 (UTC)
contributing to Gentoo via github
Tip: To get this fixed sooner, use {{Proposal}}.
This wiki page was useful to me, but I ran into a few issues which I cleared up in a forum post: https://forums.gentoo.org/viewtopic-p-8287620.html Hope it can help get more contributions from end-users. Vieri (talk) 09:33, 10 December 2018 (UTC)
- I went for Variant a: User configures a local repository, and it went smoothly. However, I do admit that users that haven't used Git or GitHub may have a tough time with this article in its current state.
- This article is always subject to further improvements. I had to do several edits here before it was finally telling me how to get to my very first PR. The article should describe the procedure top down, organized in step 1, step 2, step ... Somebody disliked the steps and removed them. People in the forums are pointed to this article, they pick some items from bottom, then fail. Will say, everybody having a hard time working with this article should help improving it.
- --Vaukai (talk) 11:32, 26 May 2024 (UTC)
- However, does the Portage tree actually have work that is suitable for such contributors? Or should those contributors instead report their bugs on Bugzilla?
- — Waldo Lemmer 07:23, 26 May 2024 (UTC)
- Pull requests is presently the preferred way of contributing to ::gentoo. Guess that's mentioned somewhere in the article. So, contributors should learn how to do PRs. Even myself one day, after having a very hard time succeeded in doing PRs. And only for stuff I don't want to see among them, I add the ebuilds to bug reports as done for bug #680770.
- --Vaukai (talk) 11:32, 26 May 2024 (UTC)
- This article is now on my to-do list, but I probably won't get to it in the near future. There's so many things I still want to do on the wiki.
- — Waldo Lemmer 11:59, 26 May 2024 (UTC)
- I'm getting the impression some people have trouble understanding the git remote ... options. Would it get more clear if replacing
- with
user $
git remote add github <UrlOfYourFork.git>
and putting larry globally in this article?user $
git remote add larry https://github.com/larry/gentoo
- --Vaukai (talk) 13:30, 28 May 2024 (UTC)
Merge Project:GitHub/Pull requests and this article
See Project Talk:GitHub/Pull requests#Merge GitHub Pull Requests and this article --Mim (talk) 13:04, 7 April 2024 (UTC)
Why name the remote "upstream"? Leads to pkgcheck errors.
The default remote name is origin, by naming it upstream the referenced pkgcheck command complains:
$ pkgcheck scan --net --commits
pkgcheck scan: error: failed running git: fatal: ambiguous argument 'origin': unknown revision or path not in the working tree.
I assume there is a reason to recommend naming it upstream? Saturnalia0 (talk) 18:49, 12 October 2024 (UTC)
- Alternatively you could name it hUgzzGTFtfunsoiojed: