16:19
<Mathieu Hofman>
Yeah I was going to suggest Reflect.ownKeys({...obj}) but only if you don't mind accessors being triggered
16:32
<ljharb>
why do you need the spread (which is what triggers the accessors)?
16:51
<bakkot>
presumably to get only the enumerable properties
21:03
<ptomato>
let's say I wanted to rebase and resuscitate https://github.com/tc39/ecma262/pull/1498 - should I try to get access to push to that branch, or start a new PR?
21:32
<Chris de Almeida>
let's say I wanted to rebase and resuscitate https://github.com/tc39/ecma262/pull/1498 - should I try to get access to push to that branch, or start a new PR?
I'm guessing you'd rather not have to fork and submit PRs to that branch from your fork?
21:36
<ptomato>
I could do that as well, but since the PR has become quite different by rebasing it on latest main, that might well be more complicated
21:36
<Chris de Almeida>
ah I didn't notice it was only one commit
21:41
<Chris de Almeida>
perhaps I am missing something but isn't the rebase the same regardless of whether you have write access to the repo?
21:51
<ptomato>
I mean, once I've rebased, would you ("you" meaning anyone with an interest in this PR) prefer that I figure out how to push the result up to the same PR, so that the previous discussions can resume uninterrupted? or is it better to open a new PR and say it supersedes the old PR?
21:56
<Chris de Almeida>
the extra step is just you'd be pushing to a branch on your fork and creating a new PR to merge your fork branch to the existing PR branch I defer to the editors on this, as they are the folks with 1. write access to the repo and would be the folks to merge your PR and 2. can decide what they prefer re: previous discussions on existing PR vs closing in favor of new PR
22:24
<Michael Ficarra>
I'm fine either way. A new PR would be less noisy, but it would be a shame to not ping the current thread participants about an update/replacement PR.