I want to keep certain GitHub workflows only in my fork.
For instance, I don't want to have .github/workflows/syncFork.yml file to be present in the upstream repo.
Is this possible in the long run?
I'm afraid ultimately, when I make PR to the original repo, it will contains this file anyway... so the best is to keep main branch between upstream and fork repos exactly the same. Right?
PS. I know I can disable workflow in the original repo:
jobs:
sync:
if
github.repository == 'my-organization/repo'
This is actually requested in discussion 9098 "Extend "on" with possibility to ignore forks (run only for the original repo) and vice versa", but not yet implemented.
The general idea would to have that workflow file in both repositories, but with a condition which test the repository name ("github.event.repository.name").
If said name if the original repository, the workflow would do nothing.
Related
My use case is this, I want to 'protect' main by denying all PRs that come from branches other than 'dev'. I am trying to build this functionality into a yaml file in GitHub actions. I tried to use the GitHub context ${{github.ref}} to isolate the source branch of the PR. While the value provided works for merge requests, github.ref on PRs stores an entirely different value (the PR number, instead of the branch name).
Is there a way to isolate the source branch of a PR, in a yaml script? The goal is to have my script check the source branch, and error if the source branch is not 'dev'.
I'd like to know how to proceed in GitHub where I could to be able to get the updates from the original repo but prevent opening a PR after each time I push a change made by myself?
The concept I want to apply this is to use a blog template for my GitHub pages. I'd like to get the feature for the future if the contributors would make any but at the same time, I'd like to prevent pushing anything to the original repo as a PR since those commits wouldn't include anything related to making a contribution to the project.
PRs aren't generated automatically, you need to explicitly create them from a branch.
You can fork a repo and work on it, and when needed, fetch and rebase from the original repo you forked from. As long as you don't explicitly use this repo to create PRs on the original repo, you should be fine.
EDIT - Adding some details as per the last comment:
Assume there's a repo called something owned by someone. You can start off by forking it to youruser using the GitHub UI. Then you can clone your fork and work on it:
git clone https://github.com/youruser/something.git
In order to get the recent changes from the original someone/something repo, you need to set it up as a remote. By convention you'd call this remote your "upstream", but you can really give it any name you choose:
git remote add upstream https://github.com/someone/something.git
Once you've added it as a remote, you can fetch from it and rebase on top of it:
git fetch upstream && git rebase upstream/main
(note that using the main branch is just an example. You can of course rebase on top of any branch in the remote repo)
I think it's not possible because when you clone or fork that repo, from that time, you start to add your own content to it since it's your personal blog. So you cannot keep getting the features from main repo. Maybe you can try rebase but I'm not sure if it works for this case. Or you can add those features to your repo by your own whenever you need them.
To be clear: I am NOT asking how to keep my fork up-to-date. I am asking a very different question, and the answer seems to be independent of GitLab or Github.
I'm curious as to why my fork doesn't need to be kept up-to-date? I have forked a project, and I have a local clone of the project with two remotes ("thetango", my fork, and "upstream", the main project). I have noticed that I don't ever really need to update my fork on either GitLab or GitHub.
I would have thought that when I pushed to create a PR (GitHub) or an MR (GitLab) the first error I would have received is that my fork is out-of-date and needs to be fast-forwarded. That never happens, which confuses me.
What git magic does GitLab and Github implement so that my fork doesn't need to be updated? Am I misunderstanding what a fork is?
When you create a pull request between your fork of a repository and a branch in the main repository, you're essentially proposing a merge between a given branch in your repository and a given branch in the main repository. The only branches which matter in that case are those two.
You may have other branches in your fork, such as the default branch and branches that include other work you're doing, but unless you're doing a pull request with one of them, how far ahead or behind they are from their corresponding branches in the main repository is irrelevant.
Now, if the branch you're creating a pull request from is far behind the one you want to merge into in the main repository, then the chance of merge conflicts increases. Therefore, it's prudent to keep your local repository up to date with the main repository if you're going to be creating pull requests, so that when you push that branch to make a PR, the branch you push is not substantially out of date.
One reason you may choose to keep your fork's main branch up to date is if you're doing independent development. For example, Git for Windows contains many Windows-specific patches which have not made it into mainline Git, so their repository is kept up to date because it's essentially an entire separate line of development.
I have a fork of an old, not-very-well-supported repository. In the fork, whenever I create a pull request from feature branch to master (i.e. the default branch), I have to specify base repository manually, every single time:
There's a similar issue with BitBucket; it has a well description, but the answers are out of scope for this one.
Can I change this behavior of GitHub UI somehow, so that new pull requests are created against specific repository?
I assume that I can achieve this by de-forking the repo, but I'd like to keep the fork relation a) due to historical reasons, b) out of respect to the original author, and c) because this is a highly error-prone process for now (there's no single button for that, unfortunately)
While changing the base branch of an existing PR is supported, changing the actual upstream repository is not for now (Q1 2022)
I would:
make a new fork of the target upstream repository
change origin of my local repository to that new fork and push my PR branches to it
make new PR from that new fork: this tie, the base repository is the right one every time.
possibly push the same feature branch to my old fork, which remains tied to the old upstream repository
I have a set of documentation for my company's API, based on the excellent Slate framework from TripIt. Per instructions, I forked their repo and proceeded to customize it. That fork lives here.
The obnoxious thing is that when contributors in my organization do a new pull request, the "base fork" on the Github "Comparing Changes" screen defaults to TripIt's repository, not my fork. They've more than once sent pull requests to the wrong place. Telling people "don't do that" isn't a particularly reliable solution. How can I set the default for where PRs are based to my fork?
GitHub keeps track of forks made through their interface and assumes pull requests will be for that original repository. You need to tell GitHub that your copy is not a fork but rather a regular repository that just happens to have identical history. Sadly, GitHub doesn't offer a good way to just uncheck the fork link. I typically solve it this way:
Clone the repository, git pull, and ensure your local copy is completely up to date.
Delete the repository on GitHub.
Create the repository on GitHub using the exact same name. Ensure it's an empty repository (don't create a README or LICENSE file.)
git push all the content back into the repository. (You may need to switch to each branch and push it, and you also may need to git push --tags.)
FRAGILE: This approach will lose existing GitHub issues and pull request comments. If you're using these heavily, this approach is probably a bad idea, and you should contact GitHub customer support to help you instead.
It is unfortunate that GitHub does not provide a way to configure the default PR target repo.
If you can delete (or get the owner to delete) the original repo A from which B was forked, then that will do the trick.
If it is not possible/agreeable to delete A, but the owner of A is willing to do the following, then the fork link gets broken, on GitHub Enterprise at least:
mark repo A as Private
mark repo A as Public again
After doing this, repo B (which was originally forked from A) will default to opening PRs against itself, rather than A.
Note: if A itself was forked from something further back in the history, then unfortunately it seems that B starts defaulting to opening PRs against that repo once A has gone. The only solution would be to apply the above to all repos upstream in the fork tree :(
Your other developers seem to have forked TripIt's repository, so that is the source/parent of their work.
In fact, if you open your own repository, you will see it hasn't been forked at all (the fork count is 0).
When they issue a merge request, by default github shows that repository as source, and so the pull request isn't sent to you.
The simplest workaround in this case is to ask your dev's to fork your repository, and work on it.
Yes, it's a bad situation...
The only solution I know of (other than deleting the fork and recreating/pushing directly from a local clone as described here ) is to have the upstream owner make the original repo PRIVATE and then return it to PUBLIC. Taking it private breaks the link to forks permanently.
But of course that requires action by the upstream owner. Github should really solve this, but it's been an issue for a very long time.