On Thursday, March 7, 2024 7:12 AM, Junio C Hamano wrote: >Ralph Seichter <github@xxxxxxxxxxx> writes: > >>> If you are illustrating a sample input, please also explain what >>> output it produces. What do the resulting lines in the config file >>> look like after you run this command? >> >> The result of running the above command looks as follows: >> >> [safe] >> directory = /home/alice/somerepo.git #I changed this. --A. Script > >That would have been a crucial piece of information to have in the proposed log message, as limiting ourselves to a comment that is >tucked after the same line as the value, things can become somewhat simplified. We may not have to worry about deletion, even >though the point about "we need to look at and typofix them with our viewers and editors" still stands. > >By the way, you may or may not have noticed it, but my example deliberately had a multi-line comment: > > $ git config --global --comment 'the reason why I added ~alice/ > is because ...' --add safe.directory /home/alice/somerepo.git > >How such a thing is handled also needs to be discussed in the proposed log message, and perhaps in the documentation as well. > >> ... My patch only supports >> single-line comments, and only as a suffix to newly added key-value >> pairs. This is a deliberate design choice. > >Such design choices need to be described in the proposed log message to help future developers who will be updating this feature, >once it gets in. > >Thanks for writing quite a lot to answer _my_ questions, but these questions are samples of things that future developers would >wonder and ask about when they want to fix bugs in, enhance, or otherwise modify the implementation of this "add comment" >feature. They may even be working on adding other features to complement the "add comment" feature, by designing support for >viewing or typofixing existing comments. When they do so, it would help them to know how this existing feature was expected to be >used and how it would fit in a larger picture (which may not have yet existed back when the feature was invented). Answering these >anticipated questions is one of the greatest things that a commit log message can do to help them. > >Thanks. I am concerned about the compatibility of this series with the community. While comments are permitted in .gitconfig files, I am not 100% sure that all stakeholders, particularly those who parse .gitconfig files in their own scripts outside of git - sure, it is their own responsibility, but this might be unexpected. I worry that this might unintentionally introduce incompatibilities into repository configurations. Is there broad consensus to do this? --Randall
