Re: [PATCH] Allow git-config to append a comment

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 7, 2024, 12:12 UTC
Message-ID: <xmqqplw6nsuz.fsf@gitster.g>
In-Reply-To: <2560952c-4495-4a71-9497-aa40032e1d2b@seichter.de>

Ralph Seichter <github@seichter.de> writes:

Show 8 quoted lines

>> 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.