All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
To: Junio C Hamano <gitster@pobox.com>, Tanay Abhra <tanayabh@gmail.com>
Cc: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>,
	git@vger.kernel.org, Ramkumar Ramachandra <artagnon@gmail.com>
Subject: Re: [PATCH 5/7] enforce `xfuncname` precedence over `funcname`
Date: Thu, 24 Jul 2014 22:22:33 +0100	[thread overview]
Message-ID: <53D17919.4020702@ramsay1.demon.co.uk> (raw)
In-Reply-To: <xmqqlhri8rdb.fsf@gitster.dls.corp.google.com>

On 24/07/14 20:54, Junio C Hamano wrote:
> Tanay Abhra <tanayabh@gmail.com> writes:
> 
>> If we take the easy way out, fixing UI mistakes would be easier,
>> just replace git_config_cache() with git_config_raw() for such cases.
> 
> I do not think that would fly well.
> 
> The kind of "let's migrate funcname users to xfuncname while still
> supporting the old uses" change will be done in the callback
> functions like userdiff_config().  But it is very typical that
> multiple config callback functions are cascaded (e.g. many
> eventually end up calling git_default_core_config()); in order to a
> workaround you suggest to help a callback in deep in a cascade chain
> would require you to see which ones among all the callback functions
> will eventually call the callback you are updating for migration and
> update all git_config() calls to git_config_raw().
> 
> If you fix it properly (assuming it is feasible; I haven't heard if
> you even tried to see how much work it would involve), you do not
> need to introduce "git_config_cached()" (or "_raw()" for that
> matter), which is a huge plus.  git_config() would instead do the
> right thing automatically, giving the same semantics except that it
> does not read the same file twice when it is known that the file has
> not changed.
> 

I haven't been following this conversation too closely, so if I have
grasped the wrong end of this stick, please accept my apologies! ;-)

Usually if you need to iterate the values in a hash-table in the order
of key insertion, you would simply link the hash-table entries into a
linked list. This assumes that the keys are distinct, or if not, that
you are using a 'multi-map' type of hash-table. Here, if memory serves
me, you are doing the 'multi' bit yourself within the single hash-table
entry for a given key; so its not quite so easy.

However, I think it you could create a list of <pointer to hash-table
entry, string-list index> pairs in the config_set and use that to do
the iteration. A bit ugly, but it should work.

HTH

ATB,
Ramsay Jones

  reply	other threads:[~2014-07-24 21:22 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-23 18:42 [PATCH 0/7] Rewrite `git_config()` using config-set API Tanay Abhra
2014-07-23 18:42 ` [PATCH 1/7] config.c: fix accuracy of line number in errors Tanay Abhra
2014-07-23 21:49   ` Junio C Hamano
2014-07-24 13:33     ` Tanay Abhra
2014-07-24 18:31       ` Junio C Hamano
2014-07-24 18:40         ` Tanay Abhra
2014-07-24 18:49           ` Matthieu Moy
2014-07-23 18:42 ` [PATCH 2/7] rewrite git_config() to use the config-set API Tanay Abhra
2014-07-23 19:55   ` Matthieu Moy
2014-07-23 19:58   ` Matthieu Moy
2014-07-23 21:58   ` Junio C Hamano
2014-07-24  6:43     ` Matthieu Moy
2014-07-23 18:42 ` [PATCH 3/7] add a test for semantic errors in config files Tanay Abhra
2014-07-23 19:55   ` Matthieu Moy
2014-07-23 22:11     ` Junio C Hamano
2014-07-24 13:56       ` Tanay Abhra
2014-07-24 14:05         ` Matthieu Moy
2014-07-24 16:41           ` Junio C Hamano
2014-07-23 18:42 ` [PATCH 4/7] add line number and file name info to `config_set` Tanay Abhra
2014-07-23 22:24   ` Junio C Hamano
2014-07-23 18:42 ` [PATCH 5/7] enforce `xfuncname` precedence over `funcname` Tanay Abhra
2014-07-23 20:05   ` Matthieu Moy
2014-07-23 21:04   ` Eric Sunshine
2014-07-23 22:34   ` Junio C Hamano
2014-07-24  6:39     ` Matthieu Moy
2014-07-24 17:09       ` Junio C Hamano
2014-07-24 18:33         ` Tanay Abhra
2014-07-24 18:47           ` Matthieu Moy
2014-07-24 19:04             ` John Keeping
2014-07-24 19:20             ` Junio C Hamano
2014-07-24 19:29               ` Tanay Abhra
2014-07-24 19:54                 ` Junio C Hamano
2014-07-24 21:22                   ` Ramsay Jones [this message]
2014-07-25  3:16                     ` Tanay Abhra
2014-07-25  6:54                       ` Matthieu Moy
2014-07-25 17:09                         ` Junio C Hamano
2014-07-25 17:45                           ` Matthieu Moy
2014-07-25 18:55                             ` Junio C Hamano
2014-07-23 18:42 ` [PATCH 6/7] config: add `git_die_config()` to the config-set API Tanay Abhra
2014-07-23 18:42 ` [PATCH 7/7] Add tests for `git_config_get_string()` Tanay Abhra
2014-07-23 20:08   ` Matthieu Moy
2014-07-23 19:38 ` [PATCH 0/7] Rewrite `git_config()` using config-set API Matthieu Moy
2014-07-23 21:44 ` Junio C Hamano
2014-07-24 15:04   ` Tanay Abhra
2014-07-24 15:39     ` Matthieu Moy
2014-07-24 15:59       ` Tanay Abhra
2014-07-24 16:17         ` Matthieu Moy
2014-07-24 20:03           ` Junio C Hamano
2014-07-24 15:06   ` [PATCH v12 1/2] add `config_set` API for caching config-like files Tanay Abhra
2014-07-24 18:41     ` Junio C Hamano
2014-07-24 15:09   ` [PATCH v12 2/2] test-config: add tests for the config_set API Tanay Abhra

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=53D17919.4020702@ramsay1.demon.co.uk \
    --to=ramsay@ramsay1.demon.co.uk \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=artagnon@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=tanayabh@gmail.com \
    /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.