search

WebAssembly / memory64

Memory with 64-bit indexes
Other
194 stars 21 forks source link

Overview.md - fix Table64 status links #60

Closed RByers closed 4 weeks ago

RByers commented 4 weeks ago

Fix URLs for Table64 status. Chromium one was a Google internal link, Firefox one was a typo pointing at the same Chromium one.

sbc100 commented 4 weeks ago

Thanks!

RByers commented 2 weeks ago

OMG it looks like this this "merged" PR was never actually added to the commit log! That's scary...

Trying again in #66

dschuff commented 2 weeks ago

It looks like this PR is against the 'master' branch, (which probably just exists because this repo was forked from spec before we switched over to 'main')

RByers commented 2 weeks ago

Oh, I definitely missed that both master and main existed. But still it's not in the commit log for the master branch either (until now that #66 landed in both), right? I swear I triple-checked that the PR and commit log I was looking at was for the same branch name (but wouldn't necessarily put it past me to be unable to see the difference between master and main).

dschuff commented 2 weeks ago

Oh, interesting, https://github.com/WebAssembly/memory64/commit/2ef4ebe2ff864753cebb4e7e5e16786396e13ae7 says that the commit is not on any branch. Maybe master got rebased or something. In any case it will be main that merges back into the main spec, and that should happen soon.

RByers commented 2 weeks ago

Oh yeah I guess a force push could have clobbered this at some point. I did think I saw that it was live (I was concerned because I was linking to this page from elsewhere where I really needed it to be accurate).

rossberg commented 2 weeks ago

I wish github had a way to reject force-pushes to main or to PR branches. Neither should ever be done, but many people keep doing it.

sbc100 commented 2 weeks ago

I don't think any human force pushed anything here. Isn't the problem here that master gets updated automatically via some automatic process such that it always point to main?

If a change lands on master branch (like this one) I guess the automatic process will discard it by resetting it to point to main again?

We should probably just drop master completely at this point.. is it still necessary some kind of transition period for some process that can't yet use master directly?

sbc100 commented 1 week ago

I was about to re-land this on main but it looks like its already on tip-ot-free master and main. Did somebody land on master by hand?

sbc100 commented 1 week ago

Sorry I saw you already landed #66.

sbc100 commented 1 week ago

I wish github had a way to reject force-pushes to main or to PR branches. Neither should ever be done, but many people keep doing it.

Under "Branches" -> "Branch Protection Rules" you have "Allow force pushes". Does that not do what you want?

rossberg commented 1 week ago

Yeah, that could be used to protect main & master, but AFAIK there is no way to generically target PR branches. You'd have to forbid it for all branches then, which is rather drastic.