Commits on Mar 15, 2024

1. config: add --comment option to add a comment …

   Introduce the ability to append comments to modifications
   made using git-config. Example usage:
   
     git config --comment "changed via script" \
       --add safe.directory /home/alice/repo.git
   
   based on the proposed patch, the output produced is:
   
     [safe]
       directory = /home/alice/repo.git #changed via script
   
   Users need to be able to distinguish between config entries made
   using automation and entries made by a human. Automation can add
   comments containing a URL pointing to explanations for the change
   made, avoiding questions from users as to why their config file
   was changed by a third party.
   
   The implementation ensures that a # character is unconditionally
   prepended to the provided comment string, and that the comment
   text is appended as a suffix to the changed key-value-pair in the
   same line of text. Multi-line comments (i.e. comments containing
   linefeed) are rejected as errors, causing Git to exit without
   making changes.
   
   Comments are aimed at humans who inspect or change their Git
   config using a pager or editor. Comments are not meant to be
   read or displayed by git-config at a later time.
   
   Signed-off-by: Ralph Seichter <[email protected]>
   Signed-off-by: Junio C Hamano <[email protected]>

   

   rseichter authored and gitster committed Mar 15, 2024
   Configuration menu

   • View commit details
   • Copy full SHA for 42d5c03
   • Browse repository at this point

   Copy the full SHA

   42d5c03 View commit details

   Browse the repository at this point in the history

2. config: fix --comment formatting …

   When git adds comments itself (like "rebase -i" todo list and
   "commit -e" log message editor), it always gives a comment
   introducer "#" followed by a Space before the message, except for
   the recently introduced "git config --comment", where the users are
   forced to say " this is my comment" if they want to add their
   comment in this usual format; otherwise their comment string will
   end up without a space after the "#".
   
   Make it more ergonomic, while keeping it possible to also use this
   unusual style, by massaging the comment string at the UI layer with
   a set of simple rules:
   
    * If the given comment string begins with '#', it is passed intact.
    * Otherwise, "# " is prefixed.
    * A string with LF in it cannot be used as a comment string.
   
   Right now there is only one "front-end" that accepts end-user
   comment string and calls the underlying machinery to add or modify
   configuration file with comments, but to make sure that the future
   callers perform similar massaging as they see fit, add a sanity
   check logic in git_config_set_multivar_in_file_gently(), which is
   the single choke point in the codepaths that consumes the comment
   string.
   
   Signed-off-by: Junio C Hamano <[email protected]>

   

   gitster committed Mar 15, 2024
   Configuration menu

   • View commit details
   • Copy full SHA for fbad334
   • Browse repository at this point

   Copy the full SHA

   fbad334 View commit details

   Browse the repository at this point in the history

3. config: allow tweaking whitespace between value and comment …

   Extending the previous step, this allows the whitespace placed after
   the value before the "# comment message" to be tweaked by tweaking
   the preprocessing rule to:
   
    * If the given comment string begins with one or more whitespace
      characters followed by '#', it is passed intact.
   
    * If the given comment string begins with '#', a Space is
      prepended.
   
    * Otherwise, " # " (Space, '#', Space) is prefixed.
   
    * A string with LF in it cannot be used as a comment string.
   
   Unlike the previous step, which unconditionally added a space after
   the value before writing the "# comment string", because the above
   preprocessing already gives a whitespace before the '#', the
   resulting string is written immediately after copying the value.
   
   And the sanity checking rule becomes
   
    * comment string after the above massaging that comes into
      git_config_set_multivar_in_file_gently() must
   
      - begin with zero or more whitespace characters followed by '#'.
      - not have a LF in it.
   
   I personally think this is over-engineered, but since I thought
   things through anyway, here it is in the patch form.  The logic to
   tweak end-user supplied comment string is encapsulated in a new
   helper function, git_config_prepare_comment_string(), so if new
   front-end callers would want to use the same massaging rules, it is
   easily reused.
   
   Unfortunately I do not think of a way to tweak the preprocessing
   rules further to optionally allow having no blank after the value,
   i.e. to produce
   
   	[section]
   		variable = value#comment
   
   (which is a valid way to say section.variable=value, by the way)
   without sacrificing the ergonomics for the more usual case, so this
   time I really stop here.
   
   Signed-off-by: Junio C Hamano <[email protected]>

   

   gitster committed Mar 15, 2024
   Configuration menu

   • View commit details
   • Copy full SHA for 31399a6
   • Browse repository at this point

   Copy the full SHA

   31399a6 View commit details

   Browse the repository at this point in the history