This probably sounds weird but I would like to fork someone's repo with all the issues attached to it. I know I can fetch changes from the original(upstream) repo such as added files or changed files but I would like to sync issues from the original repo with my repo.
I tried to sync my fork with the upstream but I see that changes in Issues (upstream) are not reflected in my repo.
If that's not possible directly, is there a workaround?
Update 1: So far, as a workaround I found this tool which allows to clone (not fork) issues to your repo. Functionality is limited, but it works https://github.com/gatewayapps/kamino
Update 2: A few more details to clarify my question. I want to be able to:
Fetch changes regularly from upstream repo.
Edit GitHub issues (create new issues, add comments, label issues, add labels) without affecting upstream repo issues.
Merge upstream issues and my issues/edits.
GitKraken can do this for you out of the box by just cloning the forked repo and selecting GitHub as the issue tracker for the selected repo.
All issues will then appear on the sidebar.
My GitHub account shows that my latest contribution was on March 21st.
When you head to commits section, you can see that I did commit today and yesterday.
Why isn't it shown in my activity?
Also - for quite a long time I have been commiting to projects from my work-account not realising that it makes me last contributor in my own project :D. Is there a way to link this email (work) with my account?
Check first the "Why are my contributions not showing up on my profile?":
Commits are only counted if they are made in the default branch or the gh-pages branch (for repositories with project sites).
If your commits are in a non-default or non-gh-pages branch and you'd like them to count toward your contributions, you will need to do one of the following:
Open a pull request to have your changes merged into the default branch or the gh-pages branch.
Change the default branch of the repository.
And you were committing on the non-default branch New-Backend-Integration.
Also, the username/email used is important: you can add emails to your GitHub account.
I've deployed an app on Netlify through continuous deployment by linking a single Github repo. I had previously been making commits to the project locally, and my contributions were being tracked for this repo. However, now that I've linked the repo to Netlify, it seems no commits or contributions I make are picked up by Github. The commits can still be seen in the Github repo and commits are updated, but the contributions no longer are tracked despite them working previously.
For some context I've checked the Github help page on contributions:
https://help.github.com/en/github/setting-up-and-managing-your-github-profile/why-are-my-contributions-not-showing-up-on-my-profile
And cannot see what rule I've violated; I'm working on this on my own, it's a standalone repo, etc etc. considering they were being tracked before for the same repo, I'm confused as to what has changed now that Netlify has been integrated.
Any help/guidance appreciated
So it had nothing to do with Netlify, but my work Mac did not have me globally installed as the commit author with my email. After that, all previous authors were wrong as being my local computer email.
To get around this I followed this tutorial to replace all previous commits with the correct author: How do I change the author and committer name/email for multiple commits?
I have a private GitHub repo that has been rebased a few times and a Jira ticket that is tracking. GitHub and Jira are linked so the commits are tagged to the Jira ticket.
The issue is that previous rebased commits still show on the Jira ticket. The GitHub history is correct? I’m assuming these are cached somewhere In Jira rather than looking through the reflog? I’ve tried a full sync for the Jura’s GitHub App but the rebased commits still show. Is there a way to remove the links?
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.