Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mozilla Firefox – Official GitHub repo

github.com

Post reply on HN
Print view View original

461–470 of 481 posts

Re: Mozilla Firefox – Official GitHub repo

#461

Post by jgrowl »

alabastervlog wrote: post #305
immibis wrote: post #280

Earlier quoted context omitted.

I am banned from GitHub because I didn't want to give them my phone number. They ignored a legally binding GDPR request to delete all my data. I haven't got around to suing them yet. Recently I also got "rate limited" after opening about three web pages. Microsoft can do something to you, and that is to arbitrarily deny you access after you've built a dependence on it, and then make you jump through hoops to get acce…

> Recently I also got "rate limited" after opening about three web pages. People who haven’t used it logged out recently may be surprised to find that they have, for some time, made the site effectively unusable without an account. Doing one search and clicking a couple results gets you temporarily blocked. It’s effectively an account-required website now.

I was pretty flabbergasted when I realized that if not logged in, I could no longer search a repository for code references.

You're really going to make me clone a project locally to do a search. I just end up using google to search github. It's so stupid.

Re: Mozilla Firefox – Official GitHub repo

#462

Post by IIsi50MHz »

baobun wrote: post #430
GabrielTFS wrote: post #424

Earlier quoted context omitted.

This seems like a poor argument. I don't like much either having the obligation to give GitHub my phone number, but it's not the same thing as a social security number, now is it ? Would you argue otherwise ?

Not US but phone number is arguably worse: You can't legally get one without tying it to govt ID anymore and tends to be tied to your current physical location.

And is commonly used for authentication codes, and like Social Security Number, it is PII that should be default-deny.

Github seems to have no legit need for a user's phone number. Since there's not even a way to tell them to go pound sand, I'd say opting out of disclosing sensitive information they don't need by not signing in/up and equating their unreasonable demand with a ban is respectable.

Re: Mozilla Firefox – Official GitHub repo

#463

Post by IIsi50MHz »

baobun wrote: post #431
LadyCailin wrote: post #388

Earlier quoted context omitted.

Hence the qualifier “generally”. I’m not saying they’re above reproach, but I am saying that companies that care far less about data security already have my phone number, such as most/all of my utilities - including my phone company. And those aren’t realistically optional.

> but I am saying that companies that care far less about data security already have my phone number Not mine and it sucks that this means I'm not welcome as FireFox contributor anymore unless I move countries just to register a monthly contract for a dedicated GitHub-accepted SIM card. Once you trigger phone-number verification requirement your account is globally shadowbanned and support blocked pending SMS code ve…

It looks like patches still get submitted to another system, and github is only used indirectly for version control.

Re: Mozilla Firefox – Official GitHub repo

#465

Post by spookie »

baq wrote: post #93
spookie wrote: post #71

Earlier quoted context omitted.

To be fair, most of the its difficulty is realized when you're stuck with a teammate rewriting history. Who, much like anyone anyone doing the same, hasn't bothered reading a book explaining things.

If you don't rewrite history in git, I don't want to bisect in your repos. If you push rewritten history to master, you're a git. Conclusion: learn your tools.

Not a single soul besides the one rewriting history knows what they're in for after the fact.

It's a recipe for disaster.

Unless you mean squashing commits, which I don't consider rewriting history, just a retelling of the fact. Still, it's something one can only do very sporadically, or at known periods of time. I

'm sure others would be more pedantic about it and this wasn't clear above.

Re: Mozilla Firefox – Official GitHub repo

#466

Post by przemo_li »

bandrami wrote: post #12

Pretty cool that Linus Torvalds invented a completely distributed version control system and 20 years later we all use it to store our code in a single place.

That's wrong hot take.

GH have forks. Those are distributed repos. You can also sync to GitLab and similar, you can front it with the likes of Gerrit, integrate some code review UIs that actually clone code, etc.

You can exercise distributed nature of git with GitHub quite well.

Re: Mozilla Firefox – Official GitHub repo

#467

Post by eru »

executesorder66 wrote: post #454
eru wrote: post #438

Earlier quoted context omitted.

Well, you misunderstood / mis-guessed what celestial sphere means. Interestingly enough, your mis-understanding also sort-of works.

Well that was a whole other topic. And luckily it links to a page that explains the whole topic of what a "celestial sphere" is. Going to the page, I see I was indeed wrong about what it was, but now I see it is an abstract sphere, with a radius that can be whatever size you want, and that is centered on the Earth, or on the observer. Once again, not so difficult to figure out even if you have no experience in the sp…

I think I see casenmgreen's is trying to get at. But they just picked an example that (to you and me) just isn't all that complicated nor bad.

Re: Mozilla Firefox – Official GitHub repo

#468

Post by eru »

mhh__ wrote: post #464
IshKebab wrote: post #423

Earlier quoted context omitted.

Why? A branch is a stack of commits.

Then whence merge commits? A branch is a commit with a hat on, strictly speaking.

Yes, a branch together with information about the intended point of divergence is a stack of commits. (Most of the time, the point of divergence is arrived at implicitly by specifying the intended mother branch, and git figures out the last common ancestor, ie the merge-base.) Let's call the branch-plus-point-of-divergence a 'PR branch'.

Though your 'stack of commits' is more like a 'stack of diffs' (at least in the Git sense of commit-is-a-snapshot-of-the-whole-repo.)

And actually, for better or worse, a PR branch is more expressive than a 'stack of commits', exactly for the reason you suggest: a PR branch can also contain merge commits, it doesn't have to be a linear chain.

Re: Mozilla Firefox – Official GitHub repo

#469

Post by mhh__ »

eru wrote: post #468
mhh__ wrote: post #464

Earlier quoted context omitted.

Then whence merge commits? A branch is a commit with a hat on, strictly speaking.

Yes, a branch together with information about the intended point of divergence is a stack of commits. (Most of the time, the point of divergence is arrived at implicitly by specifying the intended mother branch, and git figures out the last common ancestor, ie the merge-base.) Let's call the branch-plus-point-of-divergence a 'PR branch'. Though your 'stack of commits' is more like a 'stack of diffs' (at least in the…

They are often called stacked diffs yes.

Re: Mozilla Firefox – Official GitHub repo

#470

Post by eru »

mhh__ wrote: post #469
eru wrote: post #468

Earlier quoted context omitted.

Yes, a branch together with information about the intended point of divergence is a stack of commits. (Most of the time, the point of divergence is arrived at implicitly by specifying the intended mother branch, and git figures out the last common ancestor, ie the merge-base.) Let's call the branch-plus-point-of-divergence a 'PR branch'. Though your 'stack of commits' is more like a 'stack of diffs' (at least in the…

They are often called stacked diffs yes.

Basically in terms of git speak branches are mutable pointers to immutable commits. (They are basically the only mutable thing in git.)

What you'd need to do to support 'stacked diffs' or 'stacks of commits' is to keep a history of what you mutable pointers were doing. It's a 'meta-git'.

Once you have that, you could build all the convenient operations on top of that abstraction.

Btw, if memory serves right, git has some plugins (or whatever these things are called, plugins or so?) for implementing the stack of commits concept.

I don't know whether they go the 'meta-git' route that I sketched, or whether they do something less abstract.

Post reply on HN