Wikimedia is moving to Gitlab • Hacker News Board

Re: Wikimedia is moving to Gitlab

#381

Post by izietto » Thu, Oct 29, 2020, 3:17 PM UTC

u801e wrote: post #358

h0l0cube wrote: post #357

Earlier quoted context omitted.

It is one advantage to mailpatch though. A lack of vendor lock-in means you can view the patch using whatever application you want. And there's room for a better mailpatch viewer, if anyone could be bothered to make one. I'm guessing one disadvantage is the method of diff is hard-coded into the patch. It would be good to switch to word-diff, or ignore whitespace, but I'd imagine these could be applied as transformati…

> I'm guessing one disadvantage is the method of diff is hard-coded into the patch. It would be good to switch to word-diff, or ignore whitespace, but I'd imagine these could be applied as transformations on the generic format. The plugin I use in Thunderbird can switch between unified, context, and side-by-side diff views based on the same email. Adding the transformations you mentioned could be done. But one limita…

Which plugin are you using? it seems life-changing to me

Re: Wikimedia is moving to Gitlab

#382

Post by u801e » Thu, Oct 29, 2020, 3:27 PM UTC

izietto wrote: post #381

u801e wrote: post #358

Earlier quoted context omitted.

> I'm guessing one disadvantage is the method of diff is hard-coded into the patch. It would be good to switch to word-diff, or ignore whitespace, but I'd imagine these could be applied as transformations on the generic format. The plugin I use in Thunderbird can switch between unified, context, and side-by-side diff views based on the same email. Adding the transformations you mentioned could be done. But one limita…

Which plugin are you using? it seems life-changing to me

This is the one I'm using: https://github.com/Qeole/colorediffs. I installed it several years ago, so I'm not entirely sure whether you can install it on a current version of Thunderbird, but it is still working with my installation.

Re: Wikimedia is moving to Gitlab

#383

Post by mattl » Thu, Oct 29, 2020, 4:27 PM UTC

ran3824692 wrote: post #127

ognarb wrote: post #90

Earlier quoted context omitted.

Strange I never saw this behaviour on our Gitlab instance invent.kde.org.

invent.kde.org uses the nonfree google Recaptcha, that prevents it mostly. Not very nice for KDE to make people run nonfree software blob in their browser that gives up their freedom, gives up their privacy to google and trains Google's proprietary machine learning models.

Where does it use that?

Re: Wikimedia is moving to Gitlab

#384

Post by dnsmichi » Thu, Oct 29, 2020, 5:18 PM UTC

dnsmichi wrote: post #365

csdreamer7 wrote: post #281

Earlier quoted context omitted.

Or a nofollow option (add rel=nofollow)

That's a great idea. We have discussed ways of getting a trust level, and enable this for specific groups. Discourse uses the same system for preventing spam. "Good" bots detect the rel=nofollow and do not come back. See my proposal here: https://gitlab.com/gitlab-org/gitlab/-/issues/14156#note_258...

Iterating on my original thought, here is a smaller feature request for self-hosted GitLab instances. This can help GitLab.com too: https://gitlab.com/gitlab-org/gitlab/-/issues/273618

Re: Wikimedia is moving to Gitlab

#385

Post by coder543 » Thu, Oct 29, 2020, 5:22 PM UTC

dnsmichi wrote: post #384

dnsmichi wrote: post #365

Earlier quoted context omitted.

That's a great idea. We have discussed ways of getting a trust level, and enable this for specific groups. Discourse uses the same system for preventing spam. "Good" bots detect the rel=nofollow and do not come back. See my proposal here: https://gitlab.com/gitlab-org/gitlab/-/issues/14156#note_258...

Iterating on my original thought, here is a smaller feature request for self-hosted GitLab instances. This can help GitLab.com too: https://gitlab.com/gitlab-org/gitlab/-/issues/273618

I still think an even better path to success is to allow entirely disabling linking for non-admins.

Google no longer treats "nofollow" as strongly as it used to: https://webmasters.googleblog.com/2019/09/evolving-nofollow-...

Re: Wikimedia is moving to Gitlab

#386

Post by brennen » Thu, Oct 29, 2020, 6:37 PM UTC

bawolff wrote: post #326

brennen wrote: post #185

Earlier quoted context omitted.

> I think git in general should copy the approach of Fossil and include issue management and wikis along with the repo, to keep things consistent and avoid vendor lock-in. A few paragraphs I recently wrote elsewhere: The entire state of code forges as a general thing in 2020 is all the evidence you could possibly want that version control systems (Git, I'm talking about Git) are themselves massively deficient in desi…

I feel like the git model makes a lot of sense when viewed as an extension to the mailing list code review system. But most people dont want that model. However trying to fit git to other models is a bit round peg into slightly square hole imo.

Yeah, from that angle and from the perspective of 2005 it's a reasonable design, and I think what I describe above as a massive deficiency only really becomes visible in the light of everything that's happened since.

Re: Wikimedia is moving to Gitlab

#387

Post by epriest » Thu, Oct 29, 2020, 6:42 PM UTC

kevincox wrote: post #366

20after4 wrote: post #150

Earlier quoted context omitted.

What issues did you have with Phabricator? I'm maintaining phabricator for the WMF and I'm interested in anything that could improve the user experience.

I was reviewing code in mercurial's phabrictor and it was awful the most notable was that when a new version was uploaded the comments stayed on the same line number instead of sticking to the same code. There were other annoyances but it would move at least to "ok", maybe even "good" if that was fixed.

This is not (and has never been) the behavior of Phabricator.

See https://secure.phabricator.com/T7447> for discussion of why this feature can never work the way you think it should work in the general case and why I believe other implementations, particularly GitHub's implementation, make the wrong tradeoffs (GitHub simply discards comments it can't find an exact matching line for).

If you believe this feature is possible to implement the way you imagine, I invite you to suggest an implementation. I am confident I can easily provide a counterexample which your implementation gets wrong (by either porting the inline forward to a line a human user would not choose, or by failing to port an inline which is still relevant forward).

Re: Wikimedia is moving to Gitlab

#388

Post by kevincox » Thu, Oct 29, 2020, 6:54 PM UTC

epriest wrote: post #387

kevincox wrote: post #366

Earlier quoted context omitted.

I was reviewing code in mercurial's phabrictor and it was awful the most notable was that when a new version was uploaded the comments stayed on the same line number instead of sticking to the same code. There were other annoyances but it would move at least to "ok", maybe even "good" if that was fixed.

This is not (and has never been) the behavior of Phabricator. See https://secure.phabricator.com/T7447 > for discussion of why this feature can never work the way you think it should work in the general case and why I believe other implementations, particularly GitHub's implementation, make the wrong tradeoffs (GitHub simply discards comments it can't find an exact matching line for). If you believe this feature is p…

I don't need perfect, I just need good. GitHub and GitLab both have good implementations as well as every other good code review system I have used. GitHub annoying tries its hardest to hide the "outdated" comments but GitLab has the option to keep them open (they are no longer visible in the code, but remain on the discussion tab)

So I appreciate your opinion that it is impossible, but as a reviewer I much prefer when the tool tries.

Re: Wikimedia is moving to Gitlab

#389

Post by epriest » Thu, Oct 29, 2020, 6:54 PM UTC

epriest wrote: post #387

kevincox wrote: post #366

Earlier quoted context omitted.

I was reviewing code in mercurial's phabrictor and it was awful the most notable was that when a new version was uploaded the comments stayed on the same line number instead of sticking to the same code. There were other annoyances but it would move at least to "ok", maybe even "good" if that was fixed.

This is not (and has never been) the behavior of Phabricator. See https://secure.phabricator.com/T7447 > for discussion of why this feature can never work the way you think it should work in the general case and why I believe other implementations, particularly GitHub's implementation, make the wrong tradeoffs (GitHub simply discards comments it can't find an exact matching line for). If you believe this feature is p…

In particular, see https://secure.phabricator.com/T7447#112231> for a specific example which I believe GitHub's implementation gets egregiously wrong, by silently discarding an inline which is highly relevant to discussing the change.

Re: Wikimedia is moving to Gitlab

#390

Post by epriest » Thu, Oct 29, 2020, 6:57 PM UTC

kevincox wrote: post #388

epriest wrote: post #387

Earlier quoted context omitted.

This is not (and has never been) the behavior of Phabricator. See https://secure.phabricator.com/T7447 > for discussion of why this feature can never work the way you think it should work in the general case and why I believe other implementations, particularly GitHub's implementation, make the wrong tradeoffs (GitHub simply discards comments it can't find an exact matching line for). If you believe this feature is p…

I don't need perfect, I just need good. GitHub and GitLab both have good implementations as well as every other good code review system I have used. GitHub annoying tries its hardest to hide the "outdated" comments but GitLab has the option to keep them open (they are no longer visible in the code, but remain on the discussion tab) So I appreciate your opinion that it is impossible, but as a reviewer I much prefer wh…

GitHub's implementation does not do what you claim it does. GitHub has no behavior around porting and placing comments (while Phabricator does), GitHub just hides anything it can't place exactly. See my link above for a detailed description of GitHub's very simple implementation. I believe this is absolutely the wrong tradeoff.