Fix bug of branch/tag selector in the issue sidebar

[hiifong]

Fix: #32731

[yp05327]

Didn’t look into it, but why RepoBranchTagSelector is not used here?

[wxiaoguang]

TBH, this selector should be completely removed.

I don't see it is useful in modern Gitea. It seems that selector was added in old days when Gitea doesn't have proper Issue/PR support.

Anyone is really using that selector?

[yp05327]

It seems that it is used only in this pkace.

[wxiaoguang]

History: Add possibility to record branch or tag information in an issue (#780)

It does nothing more than just saving the branch/tag name into database ..............

[hiifong]

TBH, this selector should be completely removed.

I don't see it is useful in modern Gitea. It seems that selector was added in old days when Gitea doesn't have proper Issue/PR support.

Anyone is really using that selector?

I think it is not a selector here, but a hint.

[yp05327]

I don’t know the usage of this feature if we have development section in the sidebar. They seem similar.

#31899 (comment)

[shugen002]

Just some notice:
this selector , in other word, this sidebar also used in the new issue page.
if someone want to do some refactor, don't forget to check the page.

[lunny]

History: Add possibility to record branch or tag information in an issue (#780)

It does nothing more than just saving the branch/tag name into database ..............

After reviewed the history, the feature aims to record which branch/tag happened of this issue. It looks like it maybe useful when reporting a bug. It's incomplete to have filter in issues page. Since Github has no such feature, we commonly record a version, OS, and other things in the issue content. Another alternative feature is label. Users can create labels with the same name as versions and track them with labels. So is this a really necessary feature? Maybe not.

[yp05327]

I think this feature can be merged into development as it is used for developers to track in which branch/tag happened of this issue.
Or at least, giving it a description and a title. For now, I think most users don’t know the correct usage which it is designed for, especially after the implementation of development section.
Or just remove it.

[hiifong]

remove it

[wxiaoguang]

remove it

Although I suggested to remove it, actually "how to remove it" should be carefully designed.

Since this feature has been there for long time, we are not sure whether it is sure that nobody needs it.

If you just remove it completely and drop the column, then what if some 1.23 users come to complain: please give that selector back to me, what could you do?

Ideally the removal should be like this:

1. only hide it from the UI in 1.23, and collect feedbacks
2. if nobody complains and explains how to use it, remove code and drop database column in 1.24 or 1.25

[eeyrjmr]

Two questions.

1.what is shown/managed for issues that do have this information ? Will this break something for those instances that this was previously used one
2. How is this capability still realised (options were listed at in the OP)

This might not impact how we work... Just trying to collect the information. Multiple LTS feature branches at different branching from MAIN... I guess review comments can mention what branch the chreeypicked fix should be a applied to (or rewritten for). Not sure how 31899 works ATM so I can't comment

[wxiaoguang]

1.what is shown/managed for issues that do have this information ? Will this break something for those instances that this was previously used one

Nobody knows at the momemt, that's why it needs to collect feedbacks. This info is only stored in database and displayed on the UI, no other logic.

2. How is this capability still realised (options were listed at in the OP)

For example: just write the branch/tag name in the issue title? then it is still "stored in database" and "displayed on the UI"

Multiple LTS feature branches at different branching from MAIN...

It could also use other approaches, eg: labels, milestones, projects to bind an issue to a "feature"

[lunny]

Or maybe we can migrate the data to the new table in the coming PR. Then I need to support tag

[wxiaoguang]

Or maybe we can migrate the data to the new table in the coming PR. Then I need to support tag

Why? Have you figured out how end users use that field? Is it certain that the Ref could be used in your PR?

[eeyrjmr]

1.what is shown/managed for issues that do have this information ? Will this break something for those instances that this was previously used one

Nobody knows at the momemt, that's why it needs to collect feedbacks. This info is only stored in database and displayed on the UI, no other logic.

so if it is only for display purposes then how it is being used presently can be complimented (honestly in my dev setup its only me that does this out of 4 of us :) ). Be it labels or text, yes there are ways to indicate to the wider team what branch to consider or what tag to check the issue again. I am just nervous about what happens to the db etc if this is dropped/removed.

[wxiaoguang]

I am just nervous about what happens to the db etc if this is dropped/removed.

So in 1.23 we only hide it, and will drop it in next release if it is not used.

[lunny]

Is this ready to review or merge?

[shugen002]

Few question , will the new feature #31899 block next release if this pr merged?
In the other word, can we make sure there is something to record a tag/branch in next branch.

[lunny]

Few question , will the new feature #31899 block next release if this pr merged? In the other word, can we make sure there is something to record a tag/branch in next branch.

I would like #31899 merged first.

[wxiaoguang]

In the other word, can we make sure there is something to record a tag/branch in next branch.

This PR's question is: how do you use that branch/tag selector?

[lunny]

I moved #31899 from v1.23. And I think that will not be a block of this PR. The purpose is different. That PR added a development sidebar section to record which branches/commits/pull requests which resolved/will resolve the issue. But this feature is recording which branch does the issue happen.

[didim99]

Anyone is really using that selector?

Yes! Our team uses this feature for more than 20 projects with many branches. When your repo has more than 2-3 branches with different stuff (features, refactoring, etc) developing on them, it is a really useful feature to specify a branch in which issue found.

[wxiaoguang]

it is a really useful feature to specify a branch in which issue found.

@didim99 Thank you very much for the feedback, it is valuable. Just have some more questions, could you help us to understand more about "selector"?

• If it is used to "record the branch where a problem is found", what is the difference from "writing the branch name in issue title or description"? I can see the the branch selector's value isn't even searchable .... Could "using issue title/description to record the branch" be a feasible approach?
• Is "GitHub-like development sidebar (#31899)" good enough (or better) for your usage?
  • Add a new section named development in issue view sidebar to interact with branch/pr #31899

[wxiaoguang]

To avoid "breaking" in 1.23, I reverted the selector with the bug fix and added more comments. Then this PR could be merged, the discussion could be continued ( #32744 (comment) ) to figure out how to improve the branch selector in the future.

[didim99]

@wxiaoguang

what is the difference from writing the branch name in issue title or description

At first, it's a standardized approach to specifying a branch reference. Of course, using issue title/text can be a compromise solution, but it needs additional convention for team members to implement this (especially if we want to use this information for some automated pipelines, parsing a human written text is a terrible thing! At the moment I not sure in possibility to retrieve branch ref via API/webhook, but having a separate field seems better than text). Second, "selector" decreases chance of human-related mistakes such as typo (hello parsing, again). Also current implementation is good enough to handle branch renaming, clicking to branch link in issue list redirect you to actual (renamed) branch. And last (but not least), it's just convenient! You don't need to remember all branch names in repo or go to another page in another tab to find a branch name, just use selector!

Is "GitHub-like development sidebar (#31899)" good enough (or better) for your usage?

Actually, I'm not sure at the moment. I'm using Gitea (thanks, dev team, great work!) in 95% of time rather than Github in last three years. This new feature looks cool, but not sure it suitable to solve our task "specify a (existing) branch on which issue/task should be solved". I need some time to playing with this new approach to answer for your question.

Of course, I understand if maintainers decide remove this functionality without any replacement as unmaintanable/legacy/buggy stuff, but if you want to remove this only because "nobody uses this", please, no!

P. S. Our team using Gitea as global task tracker (not only for code, for everything), it's lightweight and easy to use, good enough for small team. We tried OpenProject and some other open source solutions, and Gitea's issues system wins.