I typically do not use 'origin' as a remote name; instead I use the org/user name to ensure my remote names are always unambiguous as I often have 2 or more remotes configured.
Fuzzy scheduling does not respect this setup and unless I rename the upstream remote to 'origin', I get the following warning:
⚠ Fuzzy schedule scattering without repository context. Workflows with the same name in different repositories may collide. Ensure you are in a git repository with a configured remote.
Perhaps I'm overlooking how the repository context can be specified, but I expected a few possible behaviors for this scenario:
- If there's only 1 remote, use it
- If there are 2 or more remotes, allow a CLI option for
--schedule-repo or something similar to be passed through gh aw compile
- If there's more than 1 remote and the CLI option was not specified, maybe check them to see if only 1 of them is not a fork and use it
Short of these behavior changes, I suggest augmenting the warning message to indicate that the repository context is determined by a remote named 'origin'.
I typically do not use 'origin' as a remote name; instead I use the org/user name to ensure my remote names are always unambiguous as I often have 2 or more remotes configured.
Fuzzy scheduling does not respect this setup and unless I rename the upstream remote to 'origin', I get the following warning:
Perhaps I'm overlooking how the repository context can be specified, but I expected a few possible behaviors for this scenario:
--schedule-repoor something similar to be passed throughgh aw compileShort of these behavior changes, I suggest augmenting the warning message to indicate that the repository context is determined by a remote named 'origin'.