-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Fix tag commit message #21693
Fix tag commit message #21693
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can confirm this works at least for the no-gogit case. Also I fixed the unused fmt
import.
CI failure is related. |
Checking further in the drone issue, I see that the cut-off message is delivered in "ref": "refs/tags/v1.9.1",
"head_commit": {
"id": "24c26a39ac96b6facb6f0ffb7c0cb6826ebef48c",
"message": "* update js deps"
} Comparing a commit event, it is fine there already: "ref": "refs/heads/master",
"commits": [
{
"id": "24c26a39ac96b6facb6f0ffb7c0cb6826ebef48c",
"message": "v1.9.1\n\n* update js deps"
}
"head_commit": {
"id": "24c26a39ac96b6facb6f0ffb7c0cb6826ebef48c",
"message": "v1.9.1\n\n* update js deps"
} |
Can confirm this also fixes the message in webhook tag events. Before: "message": "* test commit (silverwind)", After: "message": "0.2.2\n\n* test commit (silverwind)\n", So I'd say this is a very valuable fix. |
Test failure is still related:
|
I'm not sure anymore this is the solution we want. If there is a signature present, this sig will not match the message now... |
Not sure I understand. Isn't the PGP signature supposed to sign the whole commit message, including the first line? At least this makes me believe there is no special case that would exclude the first line. |
Maybe I'm wrong but from the example in the first post the code now extracts the message
If we would build the "tag data" again from our object we would end up with something like
and that would not match the signature. So it may not be desired to modify the message. It may be better to build the new format on the fly with a method like this? func (t *Tag) String() string {
if t.Name != "" {
if t.Message == "" {
return t.Name
} else {
return t.Name + "\n\n" + t.Message
}
}
return t.Message
} But that does not work here for example: commit.CommitMessage = tag.Message
commit.Author = tag.Tagger
commit.Signature = tag.Signature I'm a bit puzzled... |
Viewing this tag in git cli shows:
I'm thinking we should not even parse the tag when viewing repo commits as tags are just pointers to commits (with annotated tags also have a message attached).
|
If it helps, the tag messages on my repos are generated here. Note that it supplies the changelog separately as the tag message, and that the tag message excludes the version line present in the commit message. Maybe that is where the confusion comes from. |
tag.Message = tag.Name | ||
} else if tag.Name != "" { | ||
tag.Message = tag.Name + "\n\n" + tag.Message | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this joining is incorrect, we should not alter the tag message. What was wrong was just the retrieval of the tagged commit message.
tagObject.Message = tagObject.Name | ||
} else if tagObject.Name != "" { | ||
tagObject.Message = tagObject.Name + "\n\n" + tagObject.Message | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here, I think we should not alter the tag message.
@@ -108,7 +108,7 @@ func (repo *Repository) getCommitFromBatchReader(rd *bufio.Reader, id SHA1) (*Co | |||
return nil, err | |||
} | |||
|
|||
commit.CommitMessage = strings.TrimSpace(tag.Message) | |||
commit.CommitMessage = tag.Message | |||
commit.Author = tag.Tagger | |||
commit.Signature = tag.Signature |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are we overwriting the commit's data here with incorrect data from the tag? I think this is the root of the problem and I guess if we just remove these three lines, the issue may be fixed.
It is not correct to return tag data like the tag's message when commit data requested. This changes fixes commit retrieval by tag for both the latest commit in the UI and the commit info on tag webhook events. Fixes: go-gitea#21687 Replaces: go-gitea#21693
Alternative PR: #21804 |
I added back the overwriting because of the tests and that was the point where I started to have doubts. |
I see my changes are pretty similar to your first PR, minus the changes in I've added a commit to the test repo that has both a signed commit and a signed tag pointing to it, that should satisfy the failing test at least. |
The problem you might have been facing is that the test commit for |
It is not correct to return tag data when commit data is requested, so remove the hacky code that overwrote parts of a commit with parts of a tag. This fixes commit retrieval by tag for both the latest commit in the UI and the commit info on tag webhook events. Fixes: #21687 Replaces: #21693 <img width="324" alt="Screenshot 2022-11-13 at 15 26 37" src="https://user-images.githubusercontent.com/115237/201526975-736c6ea7-ad6a-467a-a823-9a63d6ecb718.png"> <img width="789" alt="image" src="https://user-images.githubusercontent.com/115237/201526876-90a13ffc-1e5c-4d76-911b-f1ae51e8eaab.png"> --------- Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
It is not correct to return tag data when commit data is requested, so remove the hacky code that overwrote parts of a commit with parts of a tag. This fixes commit retrieval by tag for both the latest commit in the UI and the commit info on tag webhook events. Fixes: go-gitea#21687 Replaces: go-gitea#21693 <img width="324" alt="Screenshot 2022-11-13 at 15 26 37" src="https://user-images.githubusercontent.com/115237/201526975-736c6ea7-ad6a-467a-a823-9a63d6ecb718.png"> <img width="789" alt="image" src="https://user-images.githubusercontent.com/115237/201526876-90a13ffc-1e5c-4d76-911b-f1ae51e8eaab.png"> --------- Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
Backport #21804 It is not correct to return tag data when commit data is requested, so remove the hacky code that overwrote parts of a commit with parts of a tag. This fixes commit retrieval by tag for both the latest commit in the UI and the commit info on tag webhook events. Fixes: #21687 Replaces: #21693 <img width="324" alt="Screenshot 2022-11-13 at 15 26 37" src="https://user-images.githubusercontent.com/115237/201526975-736c6ea7-ad6a-467a-a823-9a63d6ecb718.png"> <img width="789" alt="image" src="https://user-images.githubusercontent.com/115237/201526876-90a13ffc-1e5c-4d76-911b-f1ae51e8eaab.png"> Co-authored-by: silverwind <me@silverwind.io>
Fixes #21687
Changes in
tag.go
:parseTagData
gets called with the inputAs you can see, the message is not the same as for the commit. My change builds the expected message.
Changes in other files:
The old code overwrites data of the commit with data from the tag. That's the reason of the broken UI. Because of the wrong output from
parseTagData
the correct values were replaced with wrong values. In my tests both sides of the assignment contained the same values now so I removed the assignments. But I don't know if that's true all the time.