Specify a pull-request in --with-branch package transformations

  • Open
  • quality assurance status badge
Details
4 participants
  • Ludovic Courtès
  • Philippe SWARTVAGHER
  • raingloom
  • zimoun
Owner
unassigned
Submitted by
Philippe SWARTVAGHER
Severity
normal
P
P
Philippe SWARTVAGHER wrote on 12 Aug 2021 11:38
(address . bug-guix@gnu.org)
29e470a4-89a3-2ac1-1fbd-f4a747443fb9@inria.fr
Hello,

A nice feature would be to be able to use a pull-request as branch to
specify in the `--with-branch` transformation option.

A use-case is to use a pull-request coming from a private fork, thus we
can't use the combination `--with-git-url= with-branch=`.


As an example, if I follow
I should be able to do something like:

```bash

guix build chameleon --with-branch=chameleon=merge-requests/262/head

```

(with 262 being the pull-request I'm interested in) However, this fails:

```

guix build: erreur : impossible de récupérer la branche «
merge-requests/262/head » depuis
remote-tracking branch 'origin/merge-requests/262/head'
```

While commands stated in the documentation work well:

```bash


git fetch origin merge-requests/262/head:mr-262

git checkout mr-262

```

I guess the fetch step is lacking in the way Guix handles the
`--with-branch` transformation.


FYI, Ansible is able to do things like that (see
by combining options `refspec` and `version`.


I'm aware a workaround is to download the patch corresponding to the
pull-request and using `--with-patch`, however handling it directly with
`--with-branch` would be more handy !

Thanks,

--
Philippe SWARTVAGHER

PhD Student
TADaaM team, Inria Bordeaux Sud-Ouest
R
R
raingloom wrote on 12 Aug 2021 17:30
(name . Philippe SWARTVAGHER)(address . philippe.swartvagher@inria.fr)(address . 50026@debbugs.gnu.org)
20210812173046.53151677@riseup.net
On Thu, 12 Aug 2021 11:38:38 +0200
Philippe SWARTVAGHER <philippe.swartvagher@inria.fr> wrote:

Toggle quote (59 lines)
> Hello,
>
> A nice feature would be to be able to use a pull-request as branch to
> specify in the `--with-branch` transformation option.
>
> A use-case is to use a pull-request coming from a private fork, thus
> we can't use the combination `--with-git-url= with-branch=`.
>
>
> As an example, if I follow
> https://gitlab.inria.fr/help/user/project/merge_requests/reviews/index.md#checkout-merge-requests-locally-through-the-head-ref,
> I should be able to do something like:
>
> ```bash
>
> guix build chameleon --with-branch=chameleon=merge-requests/262/head
>
> ```
>
> (with 262 being the pull-request I'm interested in) However, this
> fails:
>
> ```
>
> guix build: erreur : impossible de récupérer la branche «
> merge-requests/262/head » depuis
> https://gitlab.inria.fr/solverstack/chameleon : cannot locate
> remote-tracking branch 'origin/merge-requests/262/head'
> ```
>
> While commands stated in the documentation work well:
>
> ```bash
>
> git clone https://gitlab.inria.fr/solverstack/chameleon && cd
> chameleon
>
> git fetch origin merge-requests/262/head:mr-262
>
> git checkout mr-262
>
> ```
>
> I guess the fetch step is lacking in the way Guix handles the
> `--with-branch` transformation.
>
>
> FYI, Ansible is able to do things like that (see
> https://docs.ansible.com/ansible/latest/collections/ansible/builtin/git_module.html),
> by combining options `refspec` and `version`.
>
>
> I'm aware a workaround is to download the patch corresponding to the
> pull-request and using `--with-patch`, however handling it directly
> with `--with-branch` would be more handy !
>
> Thanks,
>

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:
From this repo:
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.

I'm not aware of any standard way to access merge requests that would
work across all git forges, so IMHO the implementation complexity is
not worth it for such a tiny improvement. There is more important work.
P
P
Philippe SWARTVAGHER wrote on 12 Aug 2021 22:06
(name . raingloom)(address . raingloom@riseup.net)(address . 50026@debbugs.gnu.org)
3f91473c-41fd-3c93-24cb-d078e3ca22f2@inria.fr
Le 12/08/2021 à 17:30, raingloom a écrit :
Toggle quote (22 lines)
> 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.
Toggle quote (4 lines)
>
> 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).


Toggle quote (2 lines)
> 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
L
L
Ludovic Courtès wrote on 14 Sep 2021 09:43
(name . Philippe SWARTVAGHER)(address . philippe.swartvagher@inria.fr)(address . 50026@debbugs.gnu.org)
877dfj8uv9.fsf@gnu.org
Hi!

Philippe SWARTVAGHER <philippe.swartvagher@inria.fr> skribis:

Toggle quote (24 lines)
> guix build chameleon --with-branch=chameleon=merge-requests/262/head
>
> ```
>
> (with 262 being the pull-request I'm interested in) However, this fails:
>
> ```
>
> guix build: erreur : impossible de récupérer la branche «
> merge-requests/262/head » depuis
> https://gitlab.inria.fr/solverstack/chameleon : cannot locate
> remote-tracking branch 'origin/merge-requests/262/head'
> ```
>
> While commands stated in the documentation work well:
>
> ```bash
>
> git clone https://gitlab.inria.fr/solverstack/chameleon && cd chameleon
>
> git fetch origin merge-requests/262/head:mr-262
>
> git checkout mr-262

Any idea what makes this branches “special” from a Git viewpoint?

Guix uses libgit2 (via Guile-Git); perhaps there’s a feature here that
libgit2 doesn’t support, or perhaps there’s an additional step to make
to make those branches visible?

Thanks,
Ludo’.
Z
Z
zimoun wrote on 14 Sep 2021 10:12
(address . 50026@debbugs.gnu.org)
86wnnjr2xn.fsf@gmail.com
Hi,

On Tue, 14 Sep 2021 at 09:43, Ludovic Courtès <ludovic.courtes@inria.fr> wrote:
Toggle quote (18 lines)
> Philippe SWARTVAGHER <philippe.swartvagher@inria.fr> skribis:
>
>> guix build chameleon --with-branch=chameleon=merge-requests/262/head
>> guix build: erreur : impossible de récupérer la branche «
>> merge-requests/262/head » depuis
>> https://gitlab.inria.fr/solverstack/chameleon : cannot locate
>> remote-tracking branch 'origin/merge-requests/262/head'
>> ```
>>
>> While commands stated in the documentation work well:
>>
>> ```bash
>>
>> git clone https://gitlab.inria.fr/solverstack/chameleon && cd chameleon
>> git fetch origin merge-requests/262/head

> Any idea what makes this branches “special” from a Git viewpoint?

I do not know but the branch is not listed after a fresh clone:

Toggle snippet (11 lines)
$ git clone https://gitlab.inria.fr/solverstack/chameleon
$ cd chameleon
$ git branch -av
* master be19cc46 Merge branch 'fix-warning' into 'master'
remotes/origin/HEAD -> origin/master
remotes/origin/master be19cc46 Merge branch 'fix-warning' into 'master'
remotes/origin/release-0.9.2 d2b4cab3 Fix artifact
remotes/origin/release-1.0.0 da81c248 Update ChangeLog
remotes/origin/release-1.1.0 4db899ca Merge branch 'next_release' into 'master'

So I guess the GitLab Merge Requests are “special” branches. Well, I do not know
if checking the API makes sense ;-)



All the best,
simon
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 50026@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 50026
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch