You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think it would be great to have an option to disable appending of these lines. I work in a team that does not like to pollute the commit message body with these lines when we use the squash merge style.
Hm, I have to say, I am not a particular fan of this request:
It adds (unnecessary) complexity while being only minimally useful.
First of all, you would need to define where this setting will be customizable: For the whole server, for a specific user/ organization, or even for a specific repo. Depending on your choice, you have more or fewer edge cases and hence more complexity and potential bugs. There are already way too many configuration options, and there will be even more. You should still be able to use Gitea in the end; you should not be stuck configuring it for eternity.
Secondly, those lines are appended to the end of the commit message.
So, I'm thinking: If you are annoyed by these 2-4 lines, then simply stop reading before you reach them.
As they are at the end and you don't want to read them, there is no information lost in simply stopping to read there.
This means that you do not experience any loss of function and that there is a workaround that does not involve any action on your side.
Lastly, perhaps your opinion on these lines changes over time, and suddenly you do want to find out who co-authored and co-committed these changes without much hassle.
My approach on this would be the following:
If you want it, implement it yourself. If the implementation is good, I may approve it. But otherwise, I won't work on it.
I don't know what's the opinion of the other maintainers on this, but I doubt it will be too different.
There are more pressing (and useful) features to be worked on.
I would like to add that these additional lines are currently added directly as a second and third line in the commit message, in contrast to git recommendations/rules that the second line should be empty, separating the short commit message from the long description if there is one. As a result, git log --oneline gives something like
f28d164 My one-line message Co-authored-by: Me <myaddress> Co-committed-by: Me <myaddress>
I would not mind these additional lines (except that they often do not contain actually useful information) if they at least skipped a line.
Just our two cents' worth: we use gitea in a small non-profit, with a rather centralised workflow. In our use-case, the forced appending of Co-authored-by/Co-committed-by lines to each merge commit message body is not meaningful.
Being able to disable those automatically appended lines would be wonderful.
Thank you for this new global option, it is much appreciated.
Heartfelt gratitude to gitea's developers. Our users, all non-technical (small non-profit working in the humanities field) are able to use Git only because of gitea.
@wxiaoguang Thank you for asking. I actually wanted to mention, but felt it was off topic and adding unwanted noise to the ticket.
Our non-profit helps with the preservation of folklore songs. All helpers involved are computer literate, but, perhaps erring on the humanities side, are a bit averse to deeper technological aspects. CLI used is not even remotely possible, at least for now.
We have a private Gitea instance, only for our projects. Each song is transcribed using a textual form (ABC, Lilypond, MusicXML) and added to a Song repository via Gitea. Interaction happens only via Gitea GUI (no CLI). Over the course of time, somebody may add more details, or fix some incorrect notation, editing and doing a PR. All changes are checked via an internal mailing list.
Each change and each approval comes on the project's combined, concerted and aggregate effort. That is why, in our use-case, having "Co-authored-by/Co-committed-by" line is not meaningful to us.
Activity
delvh commentedon Sep 30, 2021
Hm, I have to say, I am not a particular fan of this request:
It adds (unnecessary) complexity while being only minimally useful.
First of all, you would need to define where this setting will be customizable: For the whole server, for a specific user/ organization, or even for a specific repo. Depending on your choice, you have more or fewer edge cases and hence more complexity and potential bugs. There are already way too many configuration options, and there will be even more. You should still be able to use Gitea in the end; you should not be stuck configuring it for eternity.
Secondly, those lines are appended to the end of the commit message.
So, I'm thinking: If you are annoyed by these 2-4 lines, then simply stop reading before you reach them.
As they are at the end and you don't want to read them, there is no information lost in simply stopping to read there.
This means that you do not experience any loss of function and that there is a workaround that does not involve any action on your side.
Lastly, perhaps your opinion on these lines changes over time, and suddenly you do want to find out who co-authored and co-committed these changes without much hassle.
My approach on this would be the following:
If you want it, implement it yourself. If the implementation is good, I may approve it. But otherwise, I won't work on it.
I don't know what's the opinion of the other maintainers on this, but I doubt it will be too different.
There are more pressing (and useful) features to be worked on.
zeripath commentedon Sep 30, 2021
You can change the template repo/issue/view_content/pull.tmpl L403.
We should probably extract this bit out to a subtemplate then administrators could change it this on a per user basis.
irnes commentedon Oct 1, 2021
Thank you for your answer.
The main reason for this feature request is because the git logs are in the following form:
As you can see my name appears three times in the log.
I even wonder if this is a bug if we print the same user details in the author line as well as in the message trailer:
I could try to implement this by myself so you can give your opinion and eventually merge it if makes sense.
lunny commentedon Oct 4, 2021
If the author and the co-author has the same email. It should be a bug.
viktordick commentedon Nov 11, 2021
I would like to add that these additional lines are currently added directly as a second and third line in the commit message, in contrast to git recommendations/rules that the second line should be empty, separating the short commit message from the long description if there is one. As a result,
git log --oneline
gives something likeI would not mind these additional lines (except that they often do not contain actually useful information) if they at least skipped a line.
lispstudent commentedon Nov 28, 2021
Just our two cents' worth: we use gitea in a small non-profit, with a rather centralised workflow. In our use-case, the forced appending of Co-authored-by/Co-committed-by lines to each merge commit message body is not meaningful.
Being able to disable those automatically appended lines would be wonderful.
Make Co-committed-by and co-authored-by trailers optional
Make Co-committed-by and co-authored-by trailers optional (#17848)
lispstudent commentedon Nov 29, 2021
Thank you for this new global option, it is much appreciated.
Heartfelt gratitude to gitea's developers. Our users, all non-technical (small non-profit working in the humanities field) are able to use Git only because of gitea.
wxiaoguang commentedon Nov 29, 2021
A little curious, if the users are all non-technical, how do you use git, what is your workflow?
It will make Gitea developers know more about the real users. 😊
lispstudent commentedon Nov 29, 2021
@wxiaoguang Thank you for asking. I actually wanted to mention, but felt it was off topic and adding unwanted noise to the ticket.
Our non-profit helps with the preservation of folklore songs. All helpers involved are computer literate, but, perhaps erring on the humanities side, are a bit averse to deeper technological aspects. CLI used is not even remotely possible, at least for now.
We have a private Gitea instance, only for our projects. Each song is transcribed using a textual form (ABC, Lilypond, MusicXML) and added to a Song repository via Gitea. Interaction happens only via Gitea GUI (no CLI). Over the course of time, somebody may add more details, or fix some incorrect notation, editing and doing a PR. All changes are checked via an internal mailing list.
Each change and each approval comes on the project's combined, concerted and aggregate effort. That is why, in our use-case, having "Co-authored-by/Co-committed-by" line is not meaningful to us.
Make Co-committed-by and co-authored-by trailers optional (go-gitea#1…