Am 06.07.24 um 20:15 schrieb Junio C Hamano: > There may be two classes of comments CLI "git commit" users would be > seeing, ones coming from the "git commit" itself that describe what > CLI "git commit" does (e.g., "lines starting with '#' are ignored", > "absolutely empty message buffer aborts the command"), and others > coming from project specific template and other mechanisms that > describe what the project expects (e.g., "please keep your lines > shorter than 72 columns"). > > I agree that it makes perfect sense not to show the former at all to > the end-user in git-gui UI, especially if git-gui does not ignore > lines starting with '#' or abort commit with an empty message. > > I am not sure if it is safe to strip the latter out of user's view, > though. I see your point. These two kinds of comments have different topics (usage of the tool being used vs. project conventions concerning the commit message itself). It is easy to clean only MERGE_MSG to solve the annoyance caused by the list of conflicted files. We could have this a first step, and then we can consider later whether cleaning other sources is worth it. But it would not help OP, where the comments come from the commit message template. -- Hannes
