rebase

OK lol no, this has nothing to do with D25898. Need another task for the "Missing input descriptions"

Let’s do it

If there are no objections I would be happy to accept the diff. @speck are your concerns addressed or should we continue discussion / consider other options?

In T15965#20144, @valerio.bozzolan wrote:

What is changing is, that unverified email will not match your unverified email as default, so that should need these 2 clicks manual configs (or, find a way to verify the email)

Yep, manually setting your unverified (and not verifiable) email would still be possible 👍 just two clicks are needed from this kind of pages:

Another edge case: Most of my contributions to Phorge happened as part of my work for Wikimedia. Those commits are under an email address that I no longer have access to, since I am no longer employed at the Wikimedia Foundation.

Take for example this commit that has a default (empty) identity:

"Steal credit" might actually lead to a real issue: If a new user can get themselves identified as an old, trusted, user based on commit history, their changes might not be checked as rigorously by the rest of the team - similar to the XZ Utils backdoor issue, only faster.

Limitation: to steal a commit identity, it must be the default. Sorry I forgot to say.

In T15965#20052, @speck wrote:

What can a malicious user accomplish by claiming unverified email for commits?

What can a malicious user accomplish by claiming unverified email for commits? The idea outlined here sounds right but I’d like to understand what potential harm could be done on its current state, and also whether there’s any legitimate use case for the current behavior.

I personally prefer option 1, so, removing the duplicate body. So there is more creative space to then add a more useful body in the future.

This is becoming quite frustrating in my workplace in Torino. Let's start immersion mode.

At the moment we have a multi-thread command existence checker, and it early dies if a command is not existing.

Cannot reproduce (or I misunderstand the steps):

1. Created https://github.com/aklapper/emptyrepository for testing
2. Went to phorge.localhost/diffusion/edit/form/default/?vcs=git and created emptyRepo.
3. Went to http://phorge.localhost/diffusion/26/uri/edit/208/ and set URI's I/O Type to Read Only
4. Went to http://phorge.localhost/diffusion/26/uri/edit/ and set URI to https://github.com/aklapper/emptyrepository and I/O Type to Mirror
5. Went to http://phorge.localhost/owners/paths/1/ , edited/removed existing path by setting it to: Include R26 emptyRepo / , and clicked "Save Paths"

The word solution would solve it from the expecting side, you are right. Here in my company the search is used frequently and only as a plain text search. So we have to escape the special regex signs time and again. Just would be interested if this is seen as an issue by others who uses the feature.

We can probably add a checkbox, and some nicer handling for the exception. Or possibly, just adding the word "regex" might solve this from the "user expectation" side.

Thanks for the clarification. I still think we should tackle the exception.

The word "pattern" was meant to imply "regex pattern".
Specifically - the ability to search for a regex is much more useful then a plain-text only search (and costs us basically nothing).

In T15728#15768, @valerio.bozzolan wrote:

I tried to understand the situation. Thanks.

In your opinion: on the repo view (with clone buttons) is it really important to link to the other similar "reduced" view (without clone buttons)?

I tried to understand the situation. Thanks.

I have landed my solution.

In T15645#15201, @speck wrote:

@bekay while in this area of code would you have any pointers on these other issues I’d like to fix at some point?

1. File browse widget doesn’t work unless logged in, for publicly accessible repos
2. The search results pop up width is often too narrow to show the full results path, and truncates the end of the path instead of beginning.

@bekay while in this area of code would you have any pointers on these other issues I’d like to fix at some point?

1. File browse widget doesn’t work unless logged in, for publicly accessible repos
2. The search results pop up width is often too narrow to show the full results path, and truncates the end of the path instead of beginning.

@speck @valerio.bozzolan My revision is ready to be tested 😄