You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
**Is your feature request related to a problem? Please describe.✱
The "Create Pull Request" feature uses a fixed set of URL prefixes to check for support. A better strategy is ti use the git request-pull command https://git-scm.com/docs/git-request-pull
**Describe the solution you'd like✱
use the git request-pull command to generate the pull request instead of the fixed url prefix match.
**Describe alternatives you've considered✱
None
**Additional context✱
I work with multiple customers on my machine, and the SSH keys to be used there needs to be for the specific customer. Also, git needs to use the right config. So, in my ssh config file, I have a "c1.gh" and "c1.bitbucket" and "c2.gh" and "c2.gitlab" with different keys. This means the "c1.gh" actually maps to "github.com" but the ssh agent resolves that.
The use of the standard git request-pull will help work around these issues since the remote server will always give the right urls.
I know the command is not intended for this use case, but it does work.
The text was updated successfully, but these errors were encountered:
I am not familiar with git request-pull, but from my testing it doesn't seem to do what your feature request claims it should. Namely, provide a valid URL to generate a pull request from.
Here is a sample of me trying to recreate this pull request: #4318
> git request-pull upstream-master https://github.com/ChrisMcD1/lazygit refactor-migrations
The following changes since commit 4e38a941de3baf9e50d3fd5432933d6efccff091:
Fix release script once again (#4323) (2025-02-25 22:19:56 +1100)
are available in the Git repository at:
https://github.com/ChrisMcD1/lazygit refactor-migrations
for you to fetch changes up to 264b998003593ee4f4bff2b8dee7c422c044ada4:
Migrate to only doing marshalling twice, and compare via deep copy (2025-02-25 18:33:47 -0500)
----------------------------------------------------------------
Chris McDonnell (2):
Set up benchmark on migration
Migrate to only doing marshalling twice, and compare via deep copy
pkg/config/app_config.go | 55 ++++++++-----
pkg/config/app_config_test.go | 608 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
pkg/utils/yaml_utils/yaml_utils.go | 132 ++++++++++---------------------
pkg/utils/yaml_utils/yaml_utils_test.go | 100 ++++++++++++++----------
4 files changed, 745 insertions(+), 150 deletions(-)
Which does not provide a URL. From some research I have done, it does not seem that request-pull is intended to do this either. It seems to be a way to generate a nicely formatted email requesting that another human pull in your changes from a certain remote. https://www.reddit.com/r/git/comments/jgmf2p/requestpull_how_it_works/
Can you please explain your flow, and in particular how SSH keys are involved in generating a pull request? I would expect those to only be involved in a git push and git pull type operations.
**Is your feature request related to a problem? Please describe.✱
The "Create Pull Request" feature uses a fixed set of URL prefixes to check for support. A better strategy is ti use the
git request-pull
command https://git-scm.com/docs/git-request-pull**Describe the solution you'd like✱
use the
git request-pull
command to generate the pull request instead of the fixed url prefix match.**Describe alternatives you've considered✱
None
**Additional context✱
I work with multiple customers on my machine, and the SSH keys to be used there needs to be for the specific customer. Also, git needs to use the right config. So, in my ssh config file, I have a "c1.gh" and "c1.bitbucket" and "c2.gh" and "c2.gitlab" with different keys. This means the "c1.gh" actually maps to "github.com" but the ssh agent resolves that.
The use of the standard git request-pull will help work around these issues since the remote server will always give the right urls.
I know the command is not intended for this use case, but it does work.
The text was updated successfully, but these errors were encountered: