I am a noob to github's organziation settings and all. Don't know if we need these settings for the question Im about to ask.
So what I want to achieve is to show the already opened pull request's link on a subsequent push. In the past when working with bitbucket and gitlab with a development team, the link used to appear both on the initial push to create a pull request and also on subsequent commits push to PR. But in my current workflow it only appears on initial push to create the PR. (Note I haven't been setting up repositories in the past myself and just starting to explore this area so no idea if in the past lead engineer has been adding any settings or not)
This is what I see on initial push:
And this is on subsequent push. No link to already opened pull request
What am I missing? And is it even possible to do?
Any read or keywords to search for would be appreciated.
First a remark : when running git push, lines prefixed with remote: are actually generated by something on the remote ("something" = a script or a program or ...). If you want to see something more, check if there is some setting on Github's side to re-display the merge request number when you update a branch (I must confess I don't know if and how this can be done).
If you want to find what pull request is linked to a known branch, there is a specific search filter (in the web GUI) for that : head:branch_name
As an example :
Here is how you could get PR #1037 (linked to a branch named leaksan-100-part2) on git's repository :
is:pr head:leaksan-100-part2
If you want to get this from a script, you should probably use Github's API :
the doc to Pulls API mentions a base attribute :
base string query Filter pulls by base branch name. Example: gh-pages.
Related
(For reference, here is a command line git solution How to handle review a pull-request, modify code, and merge?)
Here I'm looking for a 100% in-browser solution directly in the Github interface.
I have a repo foobar
I receive a pull request from user bob
I would like to make a few tiny edits on his modifications, and merge this PR
How to do this 100% from the Github interface, without having to open a command-line and do git ... operations?
Note: I don't want to merge bob's as it is, and do modifications later in a further commit. I would like to edit his PR before merging it to my project.
First go in the Files changed tab of the pull request. There you could edit the files with the Edit file button.
That works if you have write access to the repo and the pull request author enables Allow edits by maintainers. (Enabled by default)
The checkbox could also be checked or unchecked after creating the pull request.
Bitbucket has a feature to exclude files from the new pull request and I'm wondering if there is a similar feature in GitHub?
Scenario:
I have a Branch A that has changes in .travis.yml I pushed those
changes and create a PR I need to merge all changes in this branch
except the changes in .travis.yml file.
No, there is no such feature in GitHub (to the best of my knowledge confirmed by a quick google search).
The best alternative, excluding the proposed duplicate question for using a workaround, is to refer to this blog page, stating that:
Previously, if you wanted to use GitHub to remove files from a pull
request, you’d need to switch to the pull request branch and look for
the individual file to delete it. Now, if you have write permission,
you can click on the ‘trash’ icon for a file right in the pull
request’s “Files changed” view to make a commit and remove it.
I haven't tested this method, but I feel like it is somehow related to the rejected "alternative workaround".
I have a repository which contains a badge from Travis-CI. This badge is included in the Readme.md with the following link, as suggested by Travis-CI documentation:
[](https://travis-ci.org/nikicc/orange3-text)
However, now everyone that forks my repo will got the links to my Travis-CI badge, since it is hardcoded along with my username. I would like to achieve that all forks automatically have the links to theirs badges, not mine. Is it possible to somehow bypass this by using some variable for the username of the repository inside Readme.md files on Github? Is there any nice solution for this?
There is an alternative way to make it work:
Github: Can I see the number of downloads for a repo?
(https://github.com/andry81-devops/github-accum-stats)
It can be adopted the same way for an external service or site with data. All you need is to write a shell or any other script and call it from the github workflow action (.github/workflows/blabla.yml file).
The only thing can be a problem here is the GitHub workflow pipline call frequency, which might has a limit something about 1 call per 1 hour or 15 minutes (I didn't test it).
The idea is the same - store the status in a separate repository and does update it from a GitHub workflow action. Later you can use another action to rewrite the statistic repository below the head commit to cut off the history of changes if not need it.
I want to fork a github project to fix a couple of issues and then send a pull request.
The problem I'm running into is that I've already forked the project to adapt it for another user base.
Is it possible to create a second fork? If so, how?
When I try to fork now it just takes me to the previously created fork.
There is no way to have two forks of the same GitHub project unless you use two different GitHub accounts.
So:
Create a separate GitHub account (and verify the email)
Fork the
project
Invite your main GitHub account as a "Collaborator" (from
the settings)
You may need to add the extra step of creating an organization with the new GitHub account and inviting your main github account as an owner of the organization (also make sure your new fork is in that new organization). This will let you do things like deploy automatically to a Heroku app that is connected to your main GitHub account.
Why can't we just have multiple forks???
I mean that I could just commit and push without making a pull request, but I want to do it the offical way and I want somebody else to review the changes before I push to a public project.
GitHub pull requests do not need to be submitted from a fork; they work within a single repository as well:
Pull requests are especially useful in the fork & pull model because they provide a way to notify project maintainers about changes in your fork. However, they're also useful in the shared repository model where they're used to initiate code review and general discussion about a set of changes before being merged into a mainline branch.
There's nothing stopping you from creating a pull request even if you don't technically have to. This is often considered a best practice, and GitHub's own Flow model is largely based on pull requests.
Creating a pull request within a single repository is very similar to creating one from a fork:
Create a feature branch and push your work to that branch on GitHub
In the GitHub web UI, switch to your feature branch
Click the "Compare" & review button
The trick is not to use the master branch to create pull requests. Then you won't need to create multiple forks since you can make as many branches as you need and make pull requests against each branch independently.
Given a clean forked repo, create a dedicated branch and use that branch for the pull request.
You can create branches from the web UI (although it is not obvious).
Click the branch selection dropdown, type the new branch name in the input field, and then you'll see a clickable link Create branch: <new-branch-name> as shown below. The tricky UI part is that it might not be very obvious you should click the "create branch: xyz..." — it is NOT displayed as a button or as a hyperlink, and there is NO indication that this is a clickable link. Moreover, there is NO hint whatsoever that a branch can be created until you type in the search box — anyone would probably assume that the search box is used exclusively for searching branches, and not for creating them.
In case you already made changes directly in your fork's master branch then consider moving those changes into a dedicated branch and hard resetting the master branch to the original remote so that you keep it clean for synching with the upstream repo.
See also:
https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-and-deleting-branches-within-your-repository
The best way, recommended by github manual, is use command line git, mirror clone your repo and push it to your github.
https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/duplicating-a-repository
If you strongly prefer GitHub web interface to the command line, a GUI friendly workaround is create a new organization and fork to that new organization.
Another GUI way I can think of is to declare a fork as a template repo using repo's setting so you can create as many forks as you need.
I've previously forked jockm/vert.x and sent him a pull request. Now I want to fork vert-x/vert.x (the upstream of jockm/vert.x) and send them a different pull request. But when I click the Fork button, unsuprisingly I end up in my tjcrowder/vert.x fork of jockm/vert.x instead. Is it possible to fork both vert-x/vert.x and jockm/vert.x simultaneously such that I can send each pull requests as appropriate?
I fear the answer may be the same as for this question about the converse situation ("there's no GitHub way, but you can add a remote repo") but I'm hoping otherwise — not least because I don't see how the answer there would allow me to send pull requests to the new remote.
There's no GitHub way (small lie, see below), but there's also nothing to fear.
By definition, your fork of a fork is a fork of the original.
When you open a pull request, you get the option to choose both the origin and the destination for your pull request. The choices available there obviously depend on the fork graph, but as long as there is a path in the graph between the 2 repositories, you should be safe.
Also, since pull requests live on the website side, you don't even need to add a remote as long as you don't want to use it from git.
Now of course, you might want to reconsider your place in that graph, and make yourself a direct child of the real upstream, but that's mostly unrelated.
As said earlier there is actually a twisted way to have multiple forks, which is to create organizations and fork in them. That way you can "own" multiple repositories in the same graph. But there's really no need to go there.
Thanks to sigma's answer, I saw that not only is the upstream repo available when I go to do a pull request on the jockm/vert.x repo, but all other forks of the upstream repo are as well. So what I ended up doing was:
Deleting my fork of jockm/vert.x and instead forking vert-x/vert.x, since mostly I want to work within the main upstream repo, not jockm's version.
Creating a branch for the commit I wanted to send to jockm, and a separate branch for the commit I wanted to send to vert-x.
Making the relevant changes to each branch.
Sending pull requests for each branch to the relevant repos, since the jockm/vert.x repo is listed as a possible target for the request (along with about 200 other forks).
I used separate branches (basically topic branches) so that those commits would remain the only thing in those pull requests, since subsequent commits on the same branch are automatically added to the pull request, and these changes needed to remain isolated until/unless merged.
It seems like the better option would be to create a branch on your fork, and create a pull request from that branch. You can use branches to "fork" your version
I didn't see any specifics on "multiple forks", so I would probably end up creating another GitHub account, under which I would do the second clone, and send the different pull request to vert.x/vert.x.
Since you can have "Multiple github accounts on the same computer" (with the right ssh config file, also described here), it is a possible workaround.
Note that, however, this is supported by GitLab, with GitLab 14.0 (June 2021):
Edit default path and project name when forking
Edit default path and project name when forking
Forking a project enables you to have an exact copy of an original repository where you can experiment, apply changes, and submit contributions to the parent project.
Your forks should have meaningful names that explain their goals, and if your project is diverging, you may need multiple forks of a single project.
In this release, GitLab now supports editing the project name and project slug directly when you create a fork.
You can now create multiple forks of the same project, each with a different name, all in the same group!
See Documentation and Issue.
You could also just create a new Organization under your profile/settings. Then you can fork different states of the same original repo through the same account.