All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jakub Narębski" <jnareb@gmail.com>
To: Jeff King <peff@peff.net>, Eli Barzilay <eli@barzilay.org>
Cc: Junio C Hamano <gitster@pobox.com>,
	Andreas Schwab <schwab@linux-m68k.org>,
	git@vger.kernel.org
Subject: Re: Minor bug: git config ignores empty sections
Date: Sun, 21 Aug 2016 19:09:54 +0200	[thread overview]
Message-ID: <968003ae-4f62-ebe9-f7af-53b4e1bcf7fd@gmail.com> (raw)
In-Reply-To: <20160816123631.ckbvzustl2j37gdx@sigill.intra.peff.net>

W dniu 16.08.2016 o 14:36, Jeff King pisze:

> What I think would be much more sane in general is to parse the whole
> thing into a tree (or even a flat list of events),

List of events is cheaper on memory (though I don't think there is
an issue with size of config file), and can be turned into tree
and DOM easily.

>                                                    marking each
> syntactically as a section header, a key, a comment, a run of
> whitespace, and so on. And then do manipulations on that tree (e.g.,
> walk down to the section of interest, add a new key at the end), and
> then reformat the tree back into a stream of bytes. That lets you
> separate the policy logic from the parsing, and do high-level operations
> that might involve multiple passes or backtracking in the tree (e.g.,
> walk to the section, walk past any existing keys, walk past any comments
> but _not_ past any blank lines, then add the new key).
> 
> There are other other upsides, too. For example, the current code cannot
> write multiple unrelated keys in a single pass.
> 
> The downsides is that it's a complete rewrite of the code. So it's a
> _lot_ more work, and it carries more risk of regression. So please don't
> take this as "no, your solution isn't OK; you have to do the rewrite".
> We've been living with band-aids on the config code for a decade, so I
> am OK with one more.

So how 'git config --show-origin --list' works?  

Ah, I guess it prints as it goes, instead of parsing config file(s)
into stream of events, and printing from those.

-- 
Jakub Narębski


  reply	other threads:[~2016-08-21 17:10 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-15  1:29 Minor bug: git config ignores empty sections Eli Barzilay
2016-08-15 12:09 ` Jeff King
2016-08-15 17:34   ` Andreas Schwab
2016-08-15 18:09     ` Jeff King
2016-08-15 18:28       ` Junio C Hamano
2016-08-15 18:54         ` Andreas Schwab
2016-08-15 18:55         ` Jeff King
2016-08-15 20:49           ` Junio C Hamano
2016-08-16  4:06           ` Eli Barzilay
2016-08-16 12:36             ` Jeff King
2016-08-21 17:09               ` Jakub Narębski [this message]
2016-08-15 17:46 ` 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

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

  git send-email \
    --in-reply-to=968003ae-4f62-ebe9-f7af-53b4e1bcf7fd@gmail.com \
    --to=jnareb@gmail.com \
    --cc=eli@barzilay.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    --cc=schwab@linux-m68k.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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.