171–180 of 294 posts
I have a number of git repos that the original developers deleted - because I sync’d them to a usb stick with gitea. I think that is how you have to do it - never entrust a service, especially a free one, with your only copy of anything you value. If the YouTube algorithm nukes your account and all your videos, you should be ready to upload them to a new account. Same with anything else digital. My current is standar…
Earlier quoted context omitted.
If you worked at a company and had a fork of a private repo that company maintained of some software... do you want employees who have left to have their access to the repos removed? or an email that says that it will be removed?
> had a fork of a private repo This is the real anti-feature. You should only be able to fork a private repo using an account that is directly managed by the organization that owns the repo. That way when you revoke access to the user they automatically lose access to the fork. It's super weird that it's common to use the same account for work and non-work stuff on GitHub (myself included).
Using that model, your work on private repos wouldn't show up as "your" GitHub activity history.
Your work on external projects sanctioned by your employer (and thus using your employer's managed account) wouldn't be associated with you when you leave. For example, if you were at VMWare and contributed to the Spring project - if you left VMWare the "I did core work on Spring - its right there in a public repo" would not be associated with the account that you're saying is you.
Yes, it is weird to be mixing work accounts and personal accounts (and the mess I have had with email when my gmail account was associated with a former employer).
There's tradeoffs no matter which way that you do this... and people appear to prefer the set of "using a single account on GitHub for work and personal" and then having the follow on implications of that being that you may lose access to internal repos when you leave... which you would in either case, just its a bit more surprising when its your "personal" account.
Earlier quoted context omitted.
> My private forks are mine Your employment agreement disagrees. Blame the confusion on the blurry line GitHub draws between forking work repos into personal accounts.
Did you forget the part where this code is MIT-licensed? Yes, they don't own it, but the code is still 'theirs' to keep forever as they see fit.
The person may be able to find the original code that was MIT licensed but that doesn't mean that the work done in house is also MIT licensed and that they have any right to it.
Earlier quoted context omitted.
That is an awful lot of contortions you are doing here, to seemingly justify a word change that has had well-cemented meaning within the tech community since it's inception. We all know why this change exists, and why some people will attempt to persuade others of it's superiority. It is, however, just silly virtue signaling, and it's exhausting to hear and read. It would require some very irrational and underdevelop…
I'm willing to go out of my way to use a different word if it makes people feel better (the root of the master -> main transition). But this is the rare case where it benefits me by having to type two less characters whenever I refer to the branch! main is truly a win/win.
Which is just the thing, really. It makes no one feel better. It makes the privileged speaker feel better, with a false sense of virtue. It's a "look at how great I am" signal, nothing more.
No one is harmed or made to feel bad by using the word master. Sometimes the adults have to be present in the room, it seems.
Saving 2 characters is an equally silly excuse, but at least it has a realistic rationale. To that end, why stop at main - why not just 'm'? You can call it whatever you want in git.
I think this is under the assumption of "employee has a private fork of the company repo, then leaves, employee should not keep the fork" So when "removed as a collaborator" which apparently includes the original being deleted, you lose access to the main repo and all forks, even yours. As if leaving a company.
Microsoft does this a lot, where they assume that rules that apply to their own organisations apply to all organisations in precisely the same way. If a Microsoft IC leaves, they should lose access to all Git repos, including forks. If Joe Random open-source contributor is removed from an open source repo's access list, their fork shouldn't be wiped. But Microsoft has One Rule To Rule Them All, so they won't make exc…
Business Basic accounts being limited to 7 days of login logs is a huge middle finger to the entire small business sector. Of course they think everyone should just buy Enterprise subscriptions. It's nothing more than a corporate version of "don't be poor".
Is futurice/how-to-get-healthy a public repo? It's not visible on https://github.com/orgs/futurice/repositories If you fork a private repo and they remove you from the collaborators list, it's reasonable that your fork would be removed.
Earlier quoted context omitted.
Gitea has a cron task that pulls-in changes on an ongoing basis. If a snapshot suffices, a once off "git push" or "git clone" works (but that's not too far off from downloading a tar ball, is it?). If you want to have a up-to-date local copies of multiple repos, a SQLite-backed Gitea instance is the simplest solution. An added bonus to using Gitea is flexibility in mirroring LFS objects, which can be sent to S3 or mi…
> a SQLite-backed Gitea instance is the simplest solution Agree to disagree :) This seems like the simplest solution: git remote set-url --add --push origin git@github.com:my-user/my-repo.git git remote set-url --add --push origin /backups/repos/my-user/my-repo.git Now when you push to origin, it pushes to your local backup as well, everything up to date, no external sosftware at all :) Thanks dabber for sharing this…
Earlier quoted context omitted.
To clarify the appropriateness of this analogy: This is unexpected behaviour from Github here which may (and has, by the anecdote of OP) cause permanent data loss. Documentation is not good enough, as users should not have been expected to have read the entire documentation.
I guess this is a question of who should have been given further information. For example, whoever at the organization deleted the repo would have been given a very clear warning screen including the number of forks that would be deleted by their action prior to them doing it. On that note, an organization admin can _directly_ delete your private fork without even deleting the source repository if they want. GitHub's…
Earlier quoted context omitted.
I guess this is a question of who should have been given further information. For example, whoever at the organization deleted the repo would have been given a very clear warning screen including the number of forks that would be deleted by their action prior to them doing it. On that note, an organization admin can _directly_ delete your private fork without even deleting the source repository if they want. GitHub's…
IMO it would be useful if non-obvious behavior like that were warned about when you fork the repo. I know I'd get burned by that. I keep a local mirror of everything though.