11–20 of 21 posts
> "Group repositories together using Organizations" I've done this in the past. But then decided GitLab's ability to nest groups (i.e., have a hierarchy) made more sense. When I made the switch, GL had free private repos as well. Sure GH is bigger. But GL was / is a better tool for my needs.
> Fourth, another fork, but this time nothing has been updated for over a year. I guess the user pressed fork by mistake? A guess: they submitted a PR, and upstream never got around to merging it. My understanding is that the PR points to the fork, so if I delete my fork, the PR dies (or loses its content). Is that true?
My stance to this opinion is similar to many others here: this is all good if it works for the author, but please don’t project your idea of a “good” GitHub profile onto other people.
> Fourth, another fork, but this time nothing has been updated for over a year. I guess the user pressed fork by mistake? A guess: they submitted a PR, and upstream never got around to merging it. My understanding is that the PR points to the fork, so if I delete my fork, the PR dies (or loses its content). Is that true?
It is true. Another common case I see is people using fork as a way to snapshot stuff they depend on “just in case” (since forks don’t go away if the original is deleted or overwritten). I don’t do it, but it’s quite common. (source: I asked people why they fork my repo but never sent a PR) My stance to this opinion is similar to many others here: this is all good if it works for the author, but please don’t project…
QMK keyboard firmware is meant to be customized in this way, and it has many thousands of forks.
> Fourth, another fork, but this time nothing has been updated for over a year. I guess the user pressed fork by mistake? A guess: they submitted a PR, and upstream never got around to merging it. My understanding is that the PR points to the fork, so if I delete my fork, the PR dies (or loses its content). Is that true?
It is true. Another common case I see is people using fork as a way to snapshot stuff they depend on “just in case” (since forks don’t go away if the original is deleted or overwritten). I don’t do it, but it’s quite common. (source: I asked people why they fork my repo but never sent a PR) My stance to this opinion is similar to many others here: this is all good if it works for the author, but please don’t project…
Reasons:
1. I intend to build something that requires the repository in question, but I think I might have to extend the code in the repository itself.
2. I intend to build something that requires the repository in question but I feel more comfortable having a version of the code under my control as it will be quite central. (the snapshot)
on edit: formatting fix
Something I came across for this : https://app.astralapp.com/
You can pin 6 repos on your profile. If you want someone to see those projects, pin it up there. It shows where the repo originated from
If you want to put all your tutorial code together, copy the end results into a /sandbox folder in github, and document the README to summarize how the repo is organized.
Projects that have no relevance / tutorials should just be kept private, you could summarize courses you've done elsewhere. Sometimes I have exposed keys on there that I hadn't set an `env` variable, keeping things private is a good practice against bots
I tend to fork a lot of repos without intending to push a PR, mostly so I can understand how that codebase works, and add my own notations to it. Also, it's to keep a backup for projects I work through other organizations, there's a chance that repo might be deleted down the road. You can always `git pull upstream` at anypoint and grab the latest changes
If you want to show opensource projects you work on → pin it to your account, notate it elsewhere (e.g. portfolio page), and be on the contributor's page for that opensource repo
Aside: I've also forked repos just to remember to look at them later. I really need to get in the habbit of curating my browser bookmarks better... I don't trust them though as the syncing has sometimes borked them.
Limiting exposure of my open-source contributions to organizations adds not only another layer of search, but the opportunity for me to get passed up because my contributions to ___ weren’t immediately apparent.
A user's list of repositories can already be filtered by "type", and this handles several of his cases:
> aicioara-forks — Projects I contributed to. Anything that I pressed “fork” on goes here.
These gets automatically classified as type "Forks".
> aicioara-old — Repositories that contain code I may want to refer to later, but I do not really want to be associated with. Maybe it’s a high school or university project with no stars and which no longer reflect the way I code. I don’t have time to update them, I still need to refer to them sometime, but I don’t want them to say “hey, this is how Andrei is coding today”.
These can be marked as "Archived" (https://help.github.com/articles/archiving-a-github-reposito...)
This leaves the "boilerplate" and "gh-pages" categories, which could be indicated by adding prefixes to the corresponding repo names. If the boilerplate code is not intended to be generally useful it could be put in a private repository (especially as all users now have an unlimited number of free private repos