git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Review of git multimail

From
John Keeping <john@keeping.me.uk>
Date
Jul 3, 2013, 08:29 UTC
Message-ID
<20130703082902.GE9161@serenity.lan>
In-Reply-To
<51D3DA9A.9090604@alum.mit.edu>
On Wed, Jul 03, 2013 at 10:02:34AM +0200, Michael Haggerty wrote:
Show 50 quoted lines
> On 07/03/2013 12:21 AM, Junio C Hamano wrote:
> > Ramkumar Ramachandra <artagnon@gmail.com> writes:
> > 
> >>>     def get(self, name, default=''):
> >>>         try:
> >>>             values = self._split(read_git_output(
> >>>                     ['config', '--get', '--null', '%s.%s' % (self.section, name)],
> >>>                     env=self.env, keepends=True,
> >>>                     ))
> >>
> >> Wait, what is the point of using --null and then splitting by hand
> >> using a poorly-defined static method?  Why not drop the --null and
> >> splitlines() as usual?
> > 
> > You may actually have spotted a bug or misuse of "--get" here.
> > 
> > With this sample configuration:
> > 
> >         $ cat >sample <<\EOF
> >         [a]
> >                 one = value
> >                 one = another
> > 
> >         [b]
> >                 one = "value\nanother"
> >         EOF
> > 
> > A script cannot differentiate between them without using '--null'.
> > 
> > 	$ git config -f sample --get-all a.one
> >         $ git config -f sample --get-all b.one
> > 
> > But that matters only when you use "--get-all", not "--get".  If
> > this method wants to make sure that the user did not misuse a.one
> > as a multi-valued configuration variable, use of "--null --get-all"
> > followed by checking how many items the command gives you back would
> > be a way to do so.
> 
> No, the code in question was a simple sanity check (i.e., mostly a check
> of my own sanity and understanding of "git config" behavior) preceding
> the information-losing next line "return values[0]".  If it had been
> meant as a check that the user hadn't misconfigured the system, then I
> wouldn't have used assert but rather raised a ConfigurationException
> with an explanatory message.
> 
> I would be happy to add the checking that you described, but I didn't
> have the impression that it is the usual convention.  Does code that
> wants a single value from the config usually verify that there is
> one-and-only-one value, or does it typically just do the equivalent of
> "git config --get" and use the returned (effectively the last) value?

Doesn't "git config --get" return an error if there are multiple values? The answer is apparently "no" - I wrote the text below from git-config(1) and then checked the behaviour. This seems to be a regression in git-config (bisect running now).

I think the "correct" answer is what's below, but it doesn't work like this in current Git:

    If you want a single value then I think it's normal to just read the
    output of "git config" and let it handle the error cases, without
    needing to split the result at all.
    I think there is a different issue in the "except" block following
    the code quoted at the top though - you will return "default" if a
    key happens to be multi-valued.  The script should check the return
    code and raise a ConfigurationException if it is 2.
Previous: Junio C HamanoNext: John Keeping
Message 7 of 15 in “Review of git multimail”
  1. Ramkumar RamachandraJul 2, 2013
  2. John KeepingJul 2, 2013
  3. Ramkumar RamachandraJul 2, 2013
  4. Junio C HamanoJul 2, 2013
  5. Michael HaggertyJul 3, 2013
  6. Junio C HamanoJul 3, 2013
  7. John KeepingJul 3, 2013
  8. John KeepingJul 3, 2013
  9. Michael HaggertyJul 3, 2013
  10. Ramkumar RamachandraJul 3, 2013
  11. Ramkumar RamachandraJul 3, 2013
  12. Michael HaggertyJul 3, 2013
  13. Jed BrownJul 3, 2013
  14. Matthieu MoyJul 4, 2013
  15. Michael HaggertyJul 4, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.