unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Philippe SWARTVAGHER <philippe.swartvagher@inria.fr>
To: raingloom <raingloom@riseup.net>
Cc: 50026@debbugs.gnu.org
Subject: bug#50026: Specify a pull-request in --with-branch package transformations
Date: Thu, 12 Aug 2021 22:06:35 +0200	[thread overview]
Message-ID: <3f91473c-41fd-3c93-24cb-d078e3ca22f2@inria.fr> (raw)
In-Reply-To: <20210812173046.53151677@riseup.net>


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






  reply	other threads:[~2021-08-12 20:16 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-12  9:38 bug#50026: Specify a pull-request in --with-branch package transformations Philippe SWARTVAGHER
2021-08-12 15:30 ` raingloom
2021-08-12 20:06   ` Philippe SWARTVAGHER [this message]
2021-09-14  7:43 ` Ludovic Courtès
2021-09-14  8:12   ` zimoun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3f91473c-41fd-3c93-24cb-d078e3ca22f2@inria.fr \
    --to=philippe.swartvagher@inria.fr \
    --cc=50026@debbugs.gnu.org \
    --cc=raingloom@riseup.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).