A nice benefit of the GitHub style fork & pull request workflow is that
a git repo with the proposed patch is hosted publicly and can be used
in package managers as a temporary override while the patch is not
merged yet, e.g. in Cargo:
[patch.crates-io]
somelib = { git = "https://github.com/user/somelib", branch =
"my-patch" }
But if I send a patch to a sourcehut mailing list, I can't easily do
that, I have to manually host the patched repo somewhere :/
It would be really nice if sourcehut automatically hosted all received
patches as, for example, temporary branches in the original repo.
On Thu, Jul 30, 2020 at 03:07:31PM +0300, Greg V wrote:
> A nice benefit of the GitHub style fork & pull request workflow is that a> git repo with the proposed patch is hosted publicly and can be used in> package managers as a temporary override while the patch is not merged yet,
You push the code to a repository and then you use that repository as
the basis for a pull request. But the code being available somewhere is
a function of the first part of that, not the second. You created a
publicly available clone of the original repository that contains your
patched tree. You can push your changes to a publicly accessible place
(GitHub, Sourcehut, a simple self-hosted git repository on your web
server, etc.) regardless of the method you use to notify the original
author of your patch.
I suppose an arguable benefit of the GitHub model is that it _forces_
you to push the patched changes as a branch to a git repository
somewhere. Personally I think that's an annoying downside. If you want
to push the changes somewhere you can do so without being forced to, and
if you don't want or need to then being forced to do so is annoying.
But if you always want that anyway it might be an upside for you.
> e.g. in Cargo:> [patch.crates-io]> somelib = { git = "https://github.com/user/somelib", branch = "my-patch" }
somelib = { git = "/home/greg/code/somelib", branch = "my-patch" }
> But if I send a patch to a sourcehut mailing list, I can't easily do that, I> have to manually host the patched repo somewhere :/> It would be really nice if sourcehut automatically hosted all received> patches as, for example, temporary branches in the original repo.
My intuition is that it is a bit dangerous to add them as branches in
the _original_ repository automatically. I don't think that a code
forge should ever modify your repository automatically based on other
people's actions. When I see branches in a git repository I assume
they're branches created by the author. Anyone being able to come along
and put arbitrary potentially malicious code into a place where it shows
up under someone else's name seems like a really bad idea.
Am 01.08.20 um 02:34 schrieb Miles Rout:
> You push the code to a repository and then you use that repository as> the basis for a pull request. >> e.g. in Cargo:>> [patch.crates-io]>> somelib = { git = "https://github.com/user/somelib", branch = "my-patch" }> > somelib = { git = "/home/greg/code/somelib", branch = "my-patch" }
How is this different from a "github style" fork? You're effectively
forking the project into your own personal git repo. With the downside
that nobody knows about it.
(possibly I misunderstand your objection)
I share the inconvenience of forking just to submit a patch into a merge
request, but I didn't yet find another workflow that keeps all patches
in order and easily discoverable.
Case in point: the password-store mailing list [0] admittedly a smaller
project than many, has quite a bit of small patches lingering around,
sometimes lost in time because the maintainer probably does not the
capacity to follow up, sometimes people ask the same questions over and
over again because these patches are not discoverable or cannot be
"upvoted" and taken to the maintainer's attention.
How can the git-send-email workflow can help solve this workflow? I
think this is the question that OP asks.
Drew even explained the git-send-email workflow [1] and there's a nice
writeup about it [2] but none helped me figure out a collaborative
workflow where patches are easily discoverable.
[0] https://lists.zx2c4.com/pipermail/password-store/
[1] https://spacepub.space/videos/watch/1619c000-7c44-4330-9177-29a0854bd759
[2] https://spacekookie.de/blog/collaborating-with-git-send-email/
srht@storiepvtride.it writes:
>> I share the inconvenience of forking just to submit a patch into a merge> request, but I didn't yet find another workflow that keeps all patches> in order and easily discoverable.
Making your own copy of the repo that is available publicly is fairly
easy with git/hg. Just make your repo and push to it. Then you can
share that URL. In this case, the only distinction is in GitHub, forked
repos show up in an index somewhere, but for the distributing code that
depends on the code it's fine.
--
Malcolm Matalka
Abiogenesis Computer Systems Lab
On 7/31/20 8:34 PM, Miles Rout wrote:
> On Thu, Jul 30, 2020 at 03:07:31PM +0300, Greg V wrote:>> It would be really nice if sourcehut automatically hosted all received>> patches as, for example, temporary branches in the original repo.> > My intuition is that it is a bit dangerous to add them as branches in> the _original_ repository automatically. I don't think that a code> forge should ever modify your repository automatically based on other> people's actions. When I see branches in a git repository I assume> they're branches created by the author. Anyone being able to come along> and put arbitrary potentially malicious code into a place where it shows> up under someone else's name seems like a really bad idea.
Github actually does do this, BTW. It's not in the default fetch
refspec, but bare --mirror clones have them, and you can also do:
git config --local --add remote.origin.fetch '+refs/pull/*/head:refs/pull/*'
This will fetch pull requests which are available remotely as:
refs/pull/$PR/head
refs/pull/$PR/merge
and make them available as:
refs/pull/$PR
It's not shown as a public:
- branch, as only refs/heads/* count,
- tag, as only refs/tags/* count,
- remote, as only refs/remotes/* count,
so the namespace is largely unobjectionable and won't falsely represent
itself as anything.
The only actual danger I could possibly conceive of is an sha1 hash
collision "poisoning" the initial git object via a fetched PR, followed
by later "real" commits attempting to reuse the same hash and finding an
existing object. But again, they're not even fetched by default. And
sha1 collision isn't generally believed to be practical, at least for
git which now uses the "sha1collisiondetection" implementation of sha1.
Eventually, git will be moving to sha256 hashes anyway.
...
I'm not saying it makes sense, necessarily, to actually do this
refs/pull/* stuff, and Github may be wildly out of line for doing so.
But it's not something that no one ever did before, and it isn't
automatically dangerous the way it would be if people could outright
create random public branches.
(Also this wouldn't help Cargo on Github or anywhere else if it doesn't
fetch arbitrary hidden refs.)
--
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User