Le 12/08/2021 à 17:30, raingloom a écrit : > How is this different compared to just using the git URL and branch that > the pull request is from? > > For example, here we have a merge request: > https://gitlab.com/guile-git/guile-git/-/merge_requests/30 > From this repo: > https://gitlab.com/plattfot/guile-git > and this branch: > git_ignore_path_is_ignored > > This is how merge requests work, there is always a (pretty easy to > find) source repo and branch that should be merged into a branch of the > target repo. > > This is how you would build it in this case: > guix build \ > --with-git-url=guile-git=https://gitlab.com/plattfot/guile-git \ > --with-branch=guile-git=git_ignore_path_is_ignored guile-git > > Someone could make a script that extracts this information from the > various git forges (Gitea, GitLab, GitHub, etc), but all you get is > that you can copy one URL instead of one URL and one branch name. When the fork repository is private and you don't have access to it, you can't use --with-git-url=package=https://someforge/user/private-fork because you won't be allowed to. However, you can have access to the pull request made in the public origin repository. > > I'm not aware of any standard way to access merge requests that would > work across all git forges, Me neither, but maybe just asking Git to fetch all exisitng remote references (including these kind of special references representing pull requests) before trying to switch to the asked pull-request/branch may do the trick (it's maybe more complex than that, I don't know). > so IMHO the implementation complexity is > not worth it for such a tiny improvement. There is more important work. Sure, it was just to point out this use-case, and since other tools can handle, maybe it is not so hard to implement. I'm totally aware this is a non-prioritary corner-case. -- Philippe SWARTVAGHER PhD Student TADaaM team, Inria Bordeaux Sud-Ouest