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

431–440 of 481 posts

Re: Mozilla Firefox – Official GitHub repo

#431

Post by baobun »

LadyCailin wrote: post #388
fsflover wrote: post #386

Earlier quoted context omitted.

> generally reputable company Are you talking about Microsoft here? https://en.wikipedia.org/wiki/Microsoft#Controversies

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 verification. Aside from the privacy issue it's completely blocking people in the several countries (beyond the ones offially totally banned due to sanctions) to which GitHub won't even try to SMS/call.

Remember that registering a second account would be violating GitHub ToS.

Re: Mozilla Firefox – Official GitHub repo

#432

Post by qwertox »

IshKebab wrote: post #247
mrweasel wrote: post #146

Earlier quoted context omitted.

But Github is actually pretty good at searching for something across all files in a repo.

Not remotely as good as grep.app.

I was shocked at how fast I was able to find "Open an audio file and read as mono waveform, resampling as necessary" of whisperX in audio.py on grep.app.

It was instantaneous. But where do I go from there? I cannot navigate through the code. It shows me where I can find that string, but that's it. I also cannot look at blame to see when that line got edited.

Though thanks a lot for bringing this onto my radar.

Re: Mozilla Firefox – Official GitHub repo

#433

Post by Dylan16807 »

IshKebab wrote: post #423
mhh__ wrote: post #374

Earlier quoted context omitted.

No, they're terrible. We should be reviewing stacks of commits not branches

Why? A branch is a stack of commits.

The workflow I believe they're talking about is like a branch but you can have multiple versions of the branch as you develop and refine it.

And those updates are properly tracked by your version control, not done jankily by editing a commit and rebasing and force pushing.

Re: Mozilla Firefox – Official GitHub repo

#434

Post by nsagent »

flohofwoe wrote: post #181
guappa wrote: post #156

Earlier quoted context omitted.

Have you ever actually used svn?

Yes for about 18 years(?) in the context of game development (I don't exactly remember when we had switched from cvs to svn, but it must have been around 2003..2005) in teams up to about 100 people, working copy sizes up to about 150 GB (with most of the data being binary game asset files), and everybody working on trunk (we only used branches for releases which were branched off trunk but never merged back, only che…

Interesting. At game companies I worked at we generally used version control solutions that easily allowed storing code and assets together, such as Perforce and Alienbrain.

Re: Mozilla Firefox – Official GitHub repo

#435

Post by enos_feedler »

int_19h wrote: post #224
enos_feedler wrote: post #41

Earlier quoted context omitted.

And how are we suppose to solve this problem? By creating distributed versions of every possible component of every piece of software? Seems unrealistic. I think we should be grateful that the core underlying protocol for the most important data has the distributed properties we want. It's a lot more than we can say vs. lots of other platforms out there.

By storing issues etc in the repo itself. A git repo is just a generic object graph, after all, and objects don't necessarily describe files. There are several such solutions already. The problem is that neither of them is popular enough to become a de facto standard. And, of course, centralized git providers like GitHub have a vested interest in keeping in this way, so they are unlikely to support any such solution…

Wouldn’t it make economic sense for a git host to emerge that just did things this way and collect big pay for it? Gits been around forever and you’re idea sounds simple enough that a market of people would probably choose it on principle. There must be something more fundamental at play here.

Re: Mozilla Firefox – Official GitHub repo

#436

Post by dzaima »

probably_wrong wrote: post #410
static_motion wrote: post #405

Earlier quoted context omitted.

I'm a pretty young developer and git is the only VCS I'm familiar with, and even though it has its quirks I find it quite powerful and a perfectly adequate tool for the job. In what way is Mercurial better?

IMO Mercurial is (was?) more user-friendly. Here's a quick example: when I create a Mercurial repository Mercurial doesn't say anything, while Git yells at me that it's using "master" as its branch name but I can change it with a cryptic command. After a first commit for a file Mercurial once again doesn't say anything, while Git gives me three lines of information including the permissions for the file I just added.…

Heh, I've never noticed git commit including new file permissions on commit; definitely confusing/useless. Don't think "it prints less information" in general is a particularly good argument for user-friendliness though; if anything, it's the exact opposite.

Trying out hg for the first time - "hg init; echo hello>world; hg commit" prints a "nothing changed" and I have no clue how to get it to commit my file! Whereas git says 'use "git add ..."', and, as that's already required for starting tracking a file in both hg and git, it's not entirely unreasonable that you'll need to do "add" upon modifications too.

So in hg you have to explicitly think about file tracking and get changes for free, whereas in git you have to explicitly think about changes and get tracking for free. Obviously I'm biased, but I think "I need to tell git what changes I want committed" is a nicer model than "I need to tell hg when it should realize a file has started existing"; the former is pretty uniformly annoying, whereas I imagine the latter quite often results in adding a file, forgetting to "hg add" it, and making a bunch of commits with changes in other files as the new file is intergrated, but never actually committing the new file itself, with zero warnings.

Git's staging/index, messy as it is (and with some utterly horrible naming), is extremely powerful, and I wouldn't accept any VCS without a sane simple equivalent. Extremely do not like that "hg commit -i", adding some parts manually, and deciding that I actually need to do something else before committing, loses all the interactive deciding I've done (maybe there's a way around that, but --help and "man hg" have zero useful info on interactive mode, not even what all the different (single-char..) actions are; granted, I don't really understand "git add -i" much either, and just use a GUI when necessary). In my git workflow I basically always have some changes that I won't want to commit in the next commit.

Re: Mozilla Firefox – Official GitHub repo

#437

Post by eru »

globular-toast wrote: post #166
eru wrote: post #121

Earlier quoted context omitted.

> You have your own copy of all the branches which you are free to do whatever you want with. That's the default. But git would work just as well, if by default it was only cloning master, or even only the last few commits from master instead of the full history. You can get that behaviour today, with some options. But we can imagine an alternate universe were the defaults were different. Most of what you say, eg abo…

The point wasn't really about having your own copy of the commit history, it's about having your own copy of the refs (which is all a branch is in git). Basically, your master branch is not the same branch as GitHub's master branch or anyone else's. This is one of the things people don't really seem to understand about git. It means you don't have to do the "feature branch" thing, for example, you can just do commits…

Yes, branches are just mutable pointers. The commit history is an immutable tree and has a garbage collector to clean up.

Funny enough, this is more or less exactly the architecture some of those Haskell-weirdos would come up with. It's essentially a copy-on-write filesystem.

(Haskell people are weirdos compared to good old fashioned operating system people who use C as God intended.)

Re: Mozilla Firefox – Official GitHub repo

#438

Post by eru »

executesorder66 wrote: post #321
casenmgreen wrote: post #265

Earlier quoted context omitted.

https://en.wikipedia.org/wiki/Declination "In astronomy, declination (abbreviated dec; symbol δ) is one of the two angles that locate a point on the celestial sphere in the equatorial coordinate system, the other being hour angle. The declination angle is measured north (positive) or south (negative) of the celestial equator, along the hour circle passing through the point in question." Anyone who doesn't know what d…

I've never heard of it before, and it makes perfect sense what it is from that intro. On a celestial sphere (planet, star, etc) the declination angle (being 0 is at the equator, being 90 degrees is the north pole of the sphere, being -90 degrees, is at the south pole). You also need another angle known as the "hour angle" to locate a point on the sphere. It doesn't explain what that is, but as can be seen on Wikipedi…

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

Re: Mozilla Firefox – Official GitHub repo

#439

Post by baobun »

edelbitter wrote: post #209

So no IPv6 in the foreseeable future?

It really is a bummer that we still can't clone over IPv6 in 2025. So annoying to have to set up (and pay for) IPv4 egress proxy on so many build systems and servers just because of this.

https://github.com/orgs/community/discussions/10539

Re: Mozilla Firefox – Official GitHub repo

#440

Post by matheusmoreira »

int_19h wrote: post #421
matheusmoreira wrote: post #353

Earlier quoted context omitted.

> fawn over every contributor who creates an obviously low-effort one It's that sense of superiority that pisses me off. Many maintainers condescendingly reply "contributions welcome" in response to user complaints. People like that had better accept whatever they get. They could have easily done it themselves in all their "high quality" ways. They could have said "I don't have time for this" or even "I don't want to…

> Just slap things together until they work. As long as your problem's fixed, it's fine. It's not your baby you're taking care of. They should be grateful you even sent the patches in. Thank you for a clear and concise illustration of why some contributions are really not welcome. Just about the only thing I will agree with you on is that projects should indeed make it clear what the bar for the proper contribution i…

Making things clear and being honest about the scope and status of the project is always a good thing.

Dismissing users making feature requests and reporting bugs with a "PRs welcome" cliche is quite disrespectful and very much a sign of a superior attitude.

Post reply on HN