These seem fair concerns. Detailed multi-line commits are something that I know exist, but I've never seen much need or use for, personally, and no project teams I've ever worked on have used them. But if that's the declared preferred-approach then I agree that this feature would be actively detrimental to that and thus is not appropriate. Thanks for the responses! On Thu, Dec 24, 2020 at 12:06 AM brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > > On 2020-12-23 at 23:07:43, Mike McLean wrote: > > Indicator that the commit-rename should use the text in the control > > file (rather than the later editor prompt) could either be A) a new > > command (rename-inline, or similar) or B) existing rename command + > > "the text on this line is different from the text on the original > > commit". > > > > Obviously this wouldn't support multiline commit messages - those > > would still use the existing workflow, but adding this new feature > > wouldn't impinge upon them, so they've not lost anything. > > I know people tend to do this quite frequently, but it's extremely > uncommon for me to write such a message. I normally write a reasonably > verbose commit message, and in the vast majority of the cases where the > change is so trivial that I write a single-line commit message, I'm on a > project with sign-offs, so this wouldn't work there. > > That doesn't mean that this couldn't be useful in some cases, but I > think we're likely to encourage single-line commit messages, which I > don't think we want to do in the general case, or cause user confusion > when their commit message inline is either (a) truncated unexpectedly or > (b) not honored because the message is already multiline. So I feel > like such a feature is a foot-gun waiting to happen. > -- > brian m. carlson (he/him or they/them) > Houston, Texas, US
