| 12 Jan 2024 |
|  cmjdev. joined the room. | 01:45:01 |
|  dfcowell joined the room. | 07:48:13 |
|  giga0798 joined the room. | 10:35:30 |
|  Devon Myers joined the room. | 12:45:56 |
|  vieta joined the room. | 12:56:22 |
 pacey. | When creating a user via the /admin/users/ endpoint, is REGISTER_EMAIL_CONFIRM still honored, or does Gitea assume the e-mail is valid? | 18:24:39 |
|  devrimxyz joined the room. | 19:27:08 |
| 13 Jan 2024 |
|  pete.grace joined the room. | 00:03:18 |
|  power_orb joined the room. | 09:32:40 |
 KN4CK3R#5857 | no, it's coupled with the active status of the user | 11:03:39 |
 me.heer | Hi, I made a fix for this issue https://github.com/go-gitea/gitea/issues/22236
And I am seeing some weird behaviour which I want to discuss if anyone is familiar with it.
The issue occurs when we try to revert a merged PR.
There are 2 ways we revert a commit:
1. Using the read-tree method by making a three-way merge
2. By applying a patch
The issue occurs when it fails in both of these operations.
So first we try to fix the error in approach #1.
The issue creator already mentions the error message returned here.
2022/12/24 22:36:02 ...rvices/pull/patch.go:238:AttemptThreeWayMerge() [E] [63a77ed2] Unable to run read-tree -m! Error: exit status 128 - fatal: this operation must be run in a work tree
- fatal: this operation must be run in a work tree
This can be fixed if we clone the temporary repository without the --bare flag.
So, I fixed this by cloning a non-bare repository for this case.
Now, continuing approach #1, we run into another error.
2024/01/13 17:34:52 ...rvices/pull/patch.go:243:AttemptThreeWayMerge() [E] Unable to run read-tree -m! Error: exit status 128 - error: Entry '1' not uptodate. Cannot merge.
- error: Entry '1' not uptodate. Cannot merge.
Here, 1 is the filename that I have in my repository.
After a bit of investigating, I found out this is happening because we SetDefaultIndex in the TemporaryUploadRepository, which executes: git read-tree HEAD
For some reason, git read-tree HEAD resets the file entry.
I have parsed the git index file using this utility: https://github.com/sbp/gin
Here's the diff of index file before and after we execute SetDefaultIndex: https://www.diffchecker.com/hyOP3eJy/
The left part in this link is the index file BEFORE SetDefaultIndex, and the right part is AFTER SetDefaultIndex.
Notice the ctime, mtime are set to 0 after SetDefaultIndex. I suppose SetDefaultIndex caused git to lose the changes made to the file I have. | 12:48:43 |
| me.heer | We can fix this in 2 ways:
1. Don't call SetDefaultIndex after cloning the TemporaryUploadRepository
2. Execute git update-index --refresh after SetDefaultIndex
I can directly make the PR if that is the right place to discuss about this.
This issue is mentioned for gitea 1.17 and I am not sure what was the behaviour initially. If it worked fine without git update-index --refresh before, then this fix that I made might break something.
Does anyone have any idea about this | 12:51:12 |
| me.heer | Since this is too long for a text, I can discuss this over a voice channel if anyone wants me to | 12:52:09 |
| me.heer | * Since this is too long for a text, I can discuss this over a voice channel if anyone wants me to
Steps to reproduce:
- Click on Commit Changes on this page: https://try.gitea.io/me-heer/test/_cherrypick/1f085d7ed88a5c5db079ee8a570b1b3333d0df3e/main?ref=main&refType=branch&cherry-pick-type=revert | 12:59:09 |
|  footface. joined the room. | 15:57:50 |
|  psydroid changed their profile picture. | 21:06:37 |
| 15 Jan 2024 |
| psydroid changed their profile picture. | 08:35:44 |
| 16 Jan 2024 |
 Ryuno-Ki (André Jaenisch) | wxiaoguang: I admire your perseverance. *looks at Forgejo repositories | 06:12:52 |
|  nyncral joined the room. | 11:22:44 |
| 20 Jan 2024 |
|  839ty9 joined the room. | 05:40:45 |
| 24 Jan 2024 |
|  tobin6579 joined the room. | 06:50:00 |
| 30 Jan 2024 |
|  ke tang joined the room. | 07:46:08 |
| 1 Feb 2024 |
|  Mert Gör 🇹🇷☭ changed their profile picture. | 22:00:52 |
| 6 Feb 2024 |
|  @jojo404:matrix.org joined the room. | 15:07:33 |
| Ryuno-Ki (André Jaenisch) | *plop
I was asked for recommendations on teams in an organisation today. During my research I learned that GitHub can nest teams for access control. I couldn't find something mentioning whether this is possible with Gitea or not (no issues even). | 18:34:39 |
 jolheiser | Interesting, I didn't know teams could be nested on GH. I don't believe this is possible in Gitea currently. | 18:40:56 |
| Ryuno-Ki (André Jaenisch) | Neither did I. Haven't verified yet. | 18:43:34 |
| Ryuno-Ki (André Jaenisch) | Do you want me to file an issue to add a line to https://docs.gitea.com/usage/permissions
that nesting is not possible? Or would that raise demand for it? (In which case an issue would serve as documentation for those interested) | 18:45:31 |
| jolheiser | I think an issue would be good. It looks like there might be some vague overlap with "subgroups" e.g. https://github.com/go-gitea/gitea/issues/1872
But in general that issue (afaict) is more about structure than it is permissions. | 18:49:48 |
| jolheiser | At the very least I think it could be added to the docs page you mentioned and/or the comparison page. | 18:50:23 |
