git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Michael Haggerty <mhagger@alum.mit.edu>
To: git discussion list <git@vger.kernel.org>
Subject: RFC GSoC idea: new "git config" features
Date: Fri, 28 Feb 2014 13:51:28 +0100	[thread overview]
Message-ID: <53108650.2020708@alum.mit.edu> (raw)

I just wrote up another double-idea that has been stewing in my head for
a while:

* Allow configuration values to be unset via a config file
* Fix "git config --unset" to clean up detritus from sections that are
left empty.

These ideas are more "out there" than the last, and might be too
controversial to be implemented, let alone as a GSoC project.  I'd
definitely like some feedback.

And if you like this idea or the other one I proposed, please volunteer
to be a co-mentor!  I will be traveling for a few weeks this summer, so
I *won't* be able to be the sole mentor to a student.

I wrote up this idea in the following pull request:

    https://github.com/git/git.github.io/pull/6

I will also append the text, for your mailing-list-reading convenience.

Michael

### `git config` improvements

This project proposes the following two improvements to `git config`.
Please note that this project has a significant "political" component
to it, because some of the details of the features will be
controversial.

#### Unsetting configuration options

Some Git configuration options have an effect by their mere existence.
(I.e., setting the option to "false" or the empty string is different
than leaving it unset altogether.)  Also, some configuration options
can take multiple values.

However, there is no way for an option file to "unset" an option--that
is, to change the option back to "unset".  This is awkward, because
configuration values are read from various places (`/etc/gitconfig`,
`~/.config/git/config` or `~/.gitconfig`, and `$GIT_DIR/config`, plus
perhaps files that are included by other configuration files).
Therefore, if an option is set in one of the earlier files, there is
no way for it to be unset in a later one.  The unwanted option might
have even been set in a file like `/etc/gitconfig` that the user
doesn't have permission to modify.

It would be nice to have a syntax that can be used to unset any
previously-defined values for an option.  Perhaps

    [section "subsection"]
            !option

The above is currently currently a syntax error that causes Git to
terminate, so some thought has to go into a transition plan for
enabling this feature.  Maybe a syntax has to be invented that
conforms to the current format, like

    [unset]
            name = section.subsection.option

Because options are currently processed as they are read, this change
will require the code that reads options files to be changed
significantly.

Leave yourself a lot of time to attain a consensus on the mailing list
about how this can be done while retaining reasonable backwards
compatibility.

#### Tidy configuration files

When a configuration file is repeatedly modified, often garbage is
left behind.  For example, after

    git config my.option true
    git config --unset my.option
    git config my.option true
    git config --unset my.option

the bottom of the configuration file is left with the useless lines

    [my]
    [my]

It would be nice to clean up such garbage when rewriting the
configuration file.  This project is a bit tricky because of the
possible presence of comments.  For example, what if an empty section
looks like this:

    [my]
            # This section is for my own private settings

or this:

    [my]
    # This section is for my own private settings

or this:

    # This section is for my own private settings:
    [my]

?  In some such cases it might be desireable either to retain the
section even though it is empty, or to delete the comment along with
the section.  Very likely there will be some obvious patterns when
everybody agrees that an empty section can be deleted, and other, more
controversial cases where you will have to reach a consensus on the
mailing list about what should be done.

 - Language: C
 - Difficulty: medium
 - Possible mentors: Michael Haggerty


-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

             reply	other threads:[~2014-02-28 12:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-28 12:51 Michael Haggerty [this message]
2014-02-28 20:00 ` RFC GSoC idea: new "git config" features Junio C Hamano
2014-03-01  0:19   ` Michael Haggerty
2014-03-01  7:52     ` Jeff King
2014-03-01 11:01       ` Matthieu Moy
2014-03-14  4:43         ` Jeff King
2014-03-14 21:00           ` Junio C Hamano
2014-03-03 20:07       ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53108650.2020708@alum.mit.edu \
    --to=mhagger@alum.mit.edu \
    --cc=git@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).