Christian Couder <christian.couder@xxxxxxxxx> 于2021年3月16日周二 下午1:37写道： > > Thanks for reminding, generally speaking, we will put the trailer at the > > end of the commit messages.Take trailers in start, this should be > > something I haven't considered. > > In general what I want to say is that `git interpret-trailers` should > be considered to have sensible defaults, that can possibly be > overridden using a number of config variables (or the git -c ... > mechanism) which is a good thing. If something in it doesn't work > well, it's possible to improve it of course. Otherwise it's better to > just fully take advantage of it. > > > I notice another question: > > if we commit this again with same trailer (even same email or same commiter) > > `--trailer` will not work again, because in `interpret_trailers`, > > "if-exists" default > > set to "addIfDifferentNeighbor", I addvice enforce use "if-exists="add". > > I don't agree with using "--if-exists=add". I think the default to not > add a trailer line if it would be just above or below the same line is > better, as doing that wouldn't add much information. It's better to > encourage people to use trailers in a meaningful way. > > And again if we use "--if-exists=add", then people who would want to > take advantage of `git interpret-trailers` to customize what happens > when the trailer already exists would not be able to do it. > > For example if we don't use "--if-exists=add", then: > > - people who want to customize what happens when the trailer already > exists can do it with for example: > > git -c trailer.ifexists=addIfDifferent commit --trailer > "Signed-off-by:C O Mitter <committer@xxxxxxxxxxx>" > > - which means that people who want the "--if-exists=add" behavior can > still have it with: > > git -c trailer.ifexists=add commit --trailer "Signed-off-by:C O Mitter > <committer@xxxxxxxxxxx>" > > While if we use "--if-exists=add", then using `git -c > trailer.ifexists=... commit ...` will not customize anything as the > "--if-exists=add" command line option will override any config > customization. Well, I see what you mean, this will keep git better flexibility, give users more personalized configuration options. And this should be more in line with git design philosophy, I will follow your suggestion.
