Mislav Marohnić

Closing due to lack of info. I am not convinced that the escaped backtick was harmful, especially because this wasn't reported by anyone else.

Hi, this is an absolutely massive PR. Since I doubt it was you who wrote the code by hand, before I start reviewing it, would you do me the common...

> It is a good idea and certainly one that was under discussion. My concern, ultimately, was that by being sensitive to local state it suggests we're _running_ the local...

Thanks for the detailed reproduction steps! I think the problem is that we don't detect properly that your branch is already published to `origin` _unless_ it has git upstream configuration...

> It was one commit ahead of `@{upstream}` (`upstream/trunk`), but it was fully pushed to `@{push}` ( `origin/test`). We don't have support for `@{push}`, so only `@{upstream}` was taken into...

@tmandry I'm sorry that you almost lost your work. Are you running a recent version of gh? We've had the `--recover` option for failed `gh pr create` [since v1.3](https://github.com/cli/cli/releases/tag/v1.3.0), and...

Thanks for the idea! I'm on the fence about supporting GITHUB_REPOSITORY out of the box because I think it might lead to surprising users in some cases. For example, let's...

> But looking again, I see that once `repoOverride` is set, the factory's `BaseRepo` is mutated, which presumably overrides (as the name suggests...) Yeah, the code is not the easiest...

> * Should `gh` understand `GITHUB_REPOSITORY` as a fallback when operating in GitHub Actions (i.e. `CI=true`, `GITHUB_ACTIONS=true`) and no other repo context/override is set? That's an idea worth of pondering...

> I wonder if we need to bother restricting that behavior to `CI=true` and `GITHUB_ACTIONS=true`, though? I don't think we'd need that restriction since it feels overly specific. We could...