Pulling GitHub into the kernel process

Posted Jun 24, 2021 16:29 UTC (Thu) by tlamp (subscriber, #108540)
In reply to: Pulling GitHub into the kernel process by marcH
Parent article: Pulling GitHub into the kernel process

> - Hyperlinks from anything to anything else and back. Compare to: not long ago there wasn't even any easy way in the kernel to find older revisions of a series!

In GH there's no real revision method, I constantly click on links only to get "did not find what you're looking for" (paraphrased) as the branch got force pushed, or a pull requested abandoned/closed and the new one was not linked in the old, as that is really only happening if a user comments "replaces #12345" or the like.

> - Fine-grained notifications to anything - from nothing to everything. The recipient is in control.

x-sieve (I'm not maintaining those directly, open-xchange has a nice web-gui for it) and mailing list subscriptions are way more flexible though, GH got a bit better recently, the recipient may even be in control, but what use if the choices are "scalding hot" or "freezing cold".

So I'm really not sold that *those* are the main advantages.

Pulling GitHub into the kernel process

Posted Jun 24, 2021 17:58 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (4 responses)

Yes, Github's institutional denial of rebase being useful is…not nice. GitLab has been better AFAIK. And to plug ghostflow again, it keeps refs to every update it sees[1] if folks want archival information). Any commits that are checked get their own specific ref (the `refs/check/mr/X/Y` is the Yth update to MR X) so they stick around.

[1]Of course you can race and push twice before ghostflow fetches the middle one, but if you're winning that race, what are you really gaining?

Pulling GitHub into the kernel process

Posted Jul 26, 2021 7:12 UTC (Mon) by tpo (subscriber, #25713) [Link] (3 responses)

> And to plug ghostflow again,

When I search the nets for ghostflow, then there's almost nothing. The first result is www.ghostflow.com. When I go there the only thing I can do there is to log in. Is there a place in the electric sphere that would actually tell me what ghostflow can offer me (as opposed to me offering my email address to ghostflow)?

Pulling GitHub into the kernel process

Posted Jul 26, 2021 16:22 UTC (Mon) by mathstuf (subscriber, #69389) [Link] (2 responses)

Alas, there isn't a fancy webpage for it (it's used internally and the code is public, but no "marketing" behind it). Feel free to email me about any questions you might have (email address is in the history) or we can discuss here.

The way we deploy it is here: https://gitlab.kitware.com/utils/ghostflow-director/ (as a webhook handler for gitlab and github) and the core routines (including a nascent cli tool) are here: https://gitlab.kitware.com/utils/rust-ghostflow

Pulling GitHub into the kernel process

Posted Jul 27, 2021 9:35 UTC (Tue) by tpo (subscriber, #25713) [Link] (1 responses)

> Feel free to email me about any questions you might have (email address is in the history) or we can discuss here.

The Repo https://gitlab.kitware.com/utils/rust-ghostflow doesn't have a README.md and it's description is: "Routines which implement various parts of "ghostflow", or the git-hosted workflow.", which basically says "foo implements foo", which isn't helpful to the reader's understanding of what *actually* the purpose of that software is.

So I suggest to link from the description of https://gitlab.kitware.com/utils/rust-ghostflow to https://gitlab.kitware.com/utils/ghostflow-director/, which has minimal info on what ghostflow is, or even better to add a README.md to https://gitlab.kitware.com/utils/rust-ghostflow with minimal info that at least contains that link.

Pulling GitHub into the kernel process

Posted Jul 27, 2021 15:04 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Thanks. I'll try and carve out some time to spruce up the descriptions and such.

Pulling GitHub into the kernel process

Posted Jun 24, 2021 20:41 UTC (Thu) by marcH (subscriber, #57642) [Link] (6 responses)

> > - Hyperlinks from anything to anything else and back. Compare to: not long ago there wasn't even any easy way in the kernel to find older revisions of a series!

> In GH there's no real revision method, I constantly click on links only to get "did not find what you're looking for" (paraphrased) as the branch got force pushed

I tried (and failed) to separate into two different comments two very different Github facts:

- Hyperlinking in github is awesome. This thread.
- Github hates amending commits and force-pushing. This other post: https://lwn.net/Articles/860741/

Pulling GitHub into the kernel process

Posted Jun 25, 2021 12:49 UTC (Fri) by bluca (subscriber, #118303) [Link] (5 responses)

It's still not great, but nowadays you can click on the "force-pushed" line in a PR when a force-push happens, and you see the diff before/after the push. I believe this is relatively new, or at least I wasn't fully aware of it until this year.

Pulling GitHub into the kernel process

Posted Jun 25, 2021 15:28 UTC (Fri) by marcH (subscriber, #57642) [Link] (3 responses)

It's pretty old and is one of the very few things that works when you force push to github. However it still does not perform a "git range-diff"[*] so the output has all the rebase noise and is unusable in case of a "real" rebase with an actual base change.

[*] range-diff was implemented by Gerrit in 2018, before git itself https://gitlab.com/gitlab-org/gitlab/-/issues/24096

Pulling GitHub into the kernel process

Posted Jun 25, 2021 16:51 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (2 responses)

Just a point of note that what was upstreamed to Git came from Gerrit, but ReviewBoard was "diffing the diffs" way back in 2012 or so to extract out the useful update diff for rebases. I'm sure there is prior art elsewhere as well, but I'm not aware of it.

And yes, I've been poking GitLab occasionally to finally implement that, but they always seem to have higher priority things :/ . If you plan ahead, you can rebase the diff as-is, push, then edit the topic to make useful inter-push diffs. Conflicts obvious get lost in the noise, but it's about the best one can do on the web interfaces these days.

Pulling GitHub into the kernel process

Posted Jun 25, 2021 17:51 UTC (Fri) by marcH (subscriber, #57642) [Link] (1 responses)

Since you're in the know, any chance for the git range-diff CLI to some day have a side by side mode like Gerrit does? Diffing diffs adds another dimension so using another axis is basically necessary, the display with two columns of pluses and minuses is unreadable for everything but the simplest changes. Has this been discussed already?

Pulling GitHub into the kernel process

Posted Jun 25, 2021 20:55 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Not sure I'd consider myself "in the know" :) . Just that I have wishes for things in Git that eventually get addressed (`git range-diff` and `git bisect --first-parent` being the latest two) by other kind souls who actually have time and ability to get them done. I've scratched my own itch (`git remote get-url` is my contribution), but some of my wishes are just to big to work on in the background. I think ReviewBoard had a way to render them as a side-by-side view, but it's been so long…

Pulling GitHub into the kernel process

Posted Jun 28, 2021 15:02 UTC (Mon) by hkario (subscriber, #94864) [Link]

No, the experience is still "sub-par" at best.

I'm using Reviewable.io precisely because github makes it impossible to understand what happened during rebase if both the branch and master were updated in the mean-time.