Hi, On Wed, Nov 13, 2024 at 8:40 AM ふじを <ffjlabo@xxxxxxxxx> wrote: > > Hi everyone, > First of all, thank you for making such a tool. I am grateful to use > this tool every day. > > I encountered the issue with trailers containing Underscore or Dot characters. > I don't know if this behavior is OK as a specification, or not. So I > created the post. > > What did you do before the bug happened? (Steps to reproduce your issue) > > I added coommit with trailers which have "_" or "." in each key. > ``` > git commit -m "Test" --trailer "test_hoge: fuga" --trailer "test.hoge: > fuga" --trailer "test-hoge: fuga" > ``` > What did you expect to happen? (Expected behavior) > I expcted that they are shown like this. > ``` > # git show > Test > test_hoge: fuga > test.hoge: fuga > test-hoge: fuga > ``` > > What happened instead? (Actual behavior) > > Actually, some of them are unexpected value. > ``` > # git show > commit 70afae811def2345bead6660e0f3183662c9f4df (HEAD -> master) > Author: Your Name <you@xxxxxxxxxxx> > Date: Wed Nov 13 08:28:19 2024 +0300 > Test > test_hoge: fuga: > test.hoge: fuga: > test-hoge: fuga > ``` > > What's different between what you expected and what actually happened? > > The one for `--trailer "test-hoge: fuga"` is finished with nothing. > But The others for ones which have "_" or "." are finished with ":". Yeah, that's because '-' is allowed in trailer keys while '_' and '.' are not. The underlying issue is that when we are given a full commit message that might contain trailers and we have to parse it and find the trailers in it, the more special characters we allow in trailer keys, the higher the risk that regular text will be wrongly considered trailer keys. > Anything else you want to add: > > I want to use such characters to add some key-value received other > service (e.g. GitHub Actions) as is. > Is there any chance that characters like _ and . will be allowed in > the trailer's key? It's true that for trailers that are passed through --trailer options, we could probably relax the restrictions for trailer keys. We could also add config options to be more flexible in the general case. I think patches implementing these could be well received. > By the way, I tried the investigation for the current specification. > I hope this is helpful in some way. > > [1] This behavior occured when executing `git interpret-trailers`. > ``` > # echo msg > msg > # git interpret-trailers --trailer "test_hoge: test" --trailer > "test.hoge: test" --trailer "test-hoge: test" --in-place msg > ``` > ``` > # cat msg > msg > test_hoge: test: > test.hoge: test: > test-hoge: test > ``` Yeah `git commit --trailer ...` and `git interpret-trailers ...` use the same underlying trailer parsing code. > [2] There might be the cause in the process of the persing trailers. > if they have such characters, the whole of the trailer option values > are interpreted as one token even though they have ":" if they have > such characters. > > I checked the source code at > - parse_trailers_from_command_line_args > https://github.com/git/git/blob/564d0252ca632e0264ed670534a51d18a689ef5d/trailer.c#L748C1-L764C4 > - -> find_separator > https://github.com/git/git/blob/564d0252ca632e0264ed670534a51d18a689ef5d/trailer.c#L614C1-L642C1 Yeah, find_separator() could definitely have options to be more relaxed about what a trailer key is. Best, Christian.
