Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option to disable appending of Co-authored-by/Co-committed-by lines to the commit message body #17194

Closed
irnes opened this issue Sep 30, 2021 · 9 comments · Fixed by #17848
Closed

Comments

@irnes
Copy link

irnes commented Sep 30, 2021

Feature Description

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.

Screenshots

No response

@delvh
Copy link
Member

delvh commented 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
Copy link
Contributor

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
Copy link
Author

irnes commented 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:

commit 16aac8010eae65dd18d0394b78f0ff59daca862d
Author: Irnes Mujkanovic <irnes.mujkanovic@gmail.com>
Date:   Mon Sep 13 09:42:14 2021 +0200

    - Move saga package to internal (SRW-2025) (!414)

    Co-authored-by: Irnes Mujkanovic <irnes.mujkanovic@gmail.com>
    Co-committed-by: Irnes Mujkanovic <irnes.mujkanovic@gmail.com>

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:

if committer != sig {
     // add trailer
     message += fmt.Sprintf("\nCo-authored-by: %s\nCo-committed-by: %s\n", sig.String(), sig.String())
}

if err := git.NewCommand("commit", signArg, fmt.Sprintf("--author='%s <%s>'", sig.Name, sig.Email), "-m", message).RunInDirTimeoutEnvPipeline(env, -1, tmpBasePath, &outbuf, &errbuf); err != nil {
     log.Error("git commit [%s:%s -> %s:%s]: %v\n%s\n%s", pr.HeadRepo.FullName(), pr.HeadBranch, pr.BaseRepo.FullName(), pr.BaseBranch, err, outbuf.String(), errbuf.String())
     return "", fmt.Errorf("git commit [%s:%s -> %s:%s]: %v\n%s\n%s", pr.HeadRepo.FullName(), pr.HeadBranch, pr.BaseRepo.FullName(), pr.BaseBranch, err, outbuf.String(), errbuf.String())
}

I could try to implement this by myself so you can give your opinion and eventually merge it if makes sense.

@irnes irnes closed this as completed Oct 3, 2021
@irnes irnes reopened this Oct 3, 2021
@lunny
Copy link
Member

lunny commented Oct 4, 2021

If the author and the co-author has the same email. It should be a bug.

@viktordick
Copy link

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.

@lispstudent
Copy link

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.

zeripath added a commit to zeripath/gitea that referenced this issue Nov 28, 2021
This PR adds another option to app.ini make co-committed-by and co-authored-by trailers
optional on a per server basis.

Fix go-gitea#17194

Signed-off-by: Andrew Thornton <art27@cantab.net>
zeripath added a commit that referenced this issue Nov 29, 2021
This PR adds another option to app.ini make co-committed-by and co-authored-by trailers
optional on a per server basis.

Fix #17194

Signed-off-by: Andrew Thornton <art27@cantab.net>
@lispstudent
Copy link

lispstudent commented 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
Copy link
Contributor

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
Copy link

@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.

Chianina pushed a commit to Chianina/gitea that referenced this issue Mar 28, 2022
…7848)

This PR adds another option to app.ini make co-committed-by and co-authored-by trailers
optional on a per server basis.

Fix go-gitea#17194

Signed-off-by: Andrew Thornton <art27@cantab.net>
@go-gitea go-gitea locked and limited conversation to collaborators Apr 28, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants