git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Jeff King <peff@peff.net>
Cc: Duy Nguyen <pclouds@gmail.com>,
	Git Mailing List <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>,
	Sebastian Schuberth <sschuberth@gmail.com>,
	Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Subject: Re: [PATCH v4] config: add conditional include
Date: Sun, 17 Jul 2016 10:15:55 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.20.1607171003010.28832@virtualbox> (raw)
In-Reply-To: <20160716164747.GA24933@sigill.intra.peff.net>

Hi Peff,

On Sat, 16 Jul 2016, Jeff King wrote:

> On Sat, Jul 16, 2016 at 06:36:03PM +0200, Johannes Schindelin wrote:
> 
> > > On Sat, Jul 16, 2016 at 03:30:45PM +0200, Johannes Schindelin wrote:
> > > 
> > > > As an alternative solution to your problem, you could of course avoid all
> > > > conditional includes. Simply by adding the include.path settings
> > > > explicitly to the configs that require them. Now, that would make reasoning
> > > > and trouble-shooting simple, wouldn't it?
> > > > 
> > > > And the most beautiful aspect of it: no patch needed.
> > > 
> > > And you can just "cat" the included files directly into your
> > > .git/config. We don't even need include.path. Or ~/.gitconfig, for that
> > > matter. But sometimes dynamic things are convenient.
> > 
> > Well, apparently you are not convinced by my argument. I thought it was
> > pretty sound, but if you disagree, it cannot have been...
> 
> Heh. Don't get me wrong, I do think there's room for digging ourselves a
> deep hole with conditional includes, because anything dynamic opens up a
> question of _when_ it is evaluated, and in what context. So any
> condition should be something that we would consider static through the
> whole run of the program. Looking at the "gitdir" is right on the
> borderline of that, but I think it's OK, because we already have to
> invalidate any cached config when we setup the gitdir, because
> "$GIT_DIR/config" will have become a new source.
> 
> So I agree it's something we need to be thoughtful about, but I think
> this particular instance is useful and probably not going to bite us.

FWIW I am slightly less worried about the conditional includes (it is
already a horrible mess to figure out too-long include chains now, before
having conditional includes, for example). I am slightly more worried
about eventually needing to introduce support for something like

	[if-gitdir(...):section]
		thisSettingIsConditional = ...

or even

	[if (worktree==...):section]
		anotherConditional = ...

and then having two incompatible conditional constructs, one generic, the
other one specific to [include].

In other words, if we already introduce a conditional construct, I'd
rather have one that could easily be used for other conditions/sections
when (and if) needed.

I, for one, would rather have my repository-specific overrides in one single
file than having a bunch of files that are included conditionally and may
need to override one another: I can see the entries much easier in the
single file (and group them by section) than in the multiple files. My
working memory is just too filled up with other stuff to remember the
contents of the other file(s).

But I guess that boils down to preference.

Ciao,
Dscho

  reply	other threads:[~2016-07-17  8:16 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-26  7:06 [PATCH] config: add conditional include Nguyễn Thái Ngọc Duy
2016-06-26 18:27 ` Jeff King
2016-06-27 16:14   ` Duy Nguyen
2016-06-27 16:20     ` Jeff King
2016-06-27 16:32       ` Duy Nguyen
2016-06-27 16:35         ` Jeff King
2016-06-28 17:26 ` [PATCH v2 0/2] Config " Nguyễn Thái Ngọc Duy
2016-06-28 17:26   ` [PATCH v2 1/2] add skip_prefix_mem helper Nguyễn Thái Ngọc Duy
2016-06-28 17:26   ` [PATCH v2 2/2] config: add conditional include Nguyễn Thái Ngọc Duy
2016-06-28 20:49     ` Jeff King
2016-06-29  4:06       ` Duy Nguyen
2016-06-28 23:11     ` Eric Sunshine
2016-07-12 16:42     ` [PATCH v3] " Nguyễn Thái Ngọc Duy
2016-07-13  7:21       ` Matthieu Moy
2016-07-13  7:26         ` Jeff King
2016-07-13 12:48           ` Matthieu Moy
2016-07-13 15:57         ` Duy Nguyen
2016-07-14 15:33       ` [PATCH v4] " Nguyễn Thái Ngọc Duy
2016-07-14 15:53         ` Johannes Schindelin
2016-07-14 16:13           ` Duy Nguyen
2016-07-16 13:30             ` Johannes Schindelin
2016-07-16 14:48               ` Duy Nguyen
2016-07-16 15:08               ` Jeff King
2016-07-16 16:36                 ` Johannes Schindelin
2016-07-16 16:47                   ` Jeff King
2016-07-17  8:15                     ` Johannes Schindelin [this message]
2016-07-20 13:31                       ` Jeff King
2016-07-20 22:07                         ` Junio C Hamano
2016-07-20 16:39                     ` Jakub Narębski
2016-08-13  8:40         ` Duy Nguyen
2016-08-19 13:54           ` Jeff King
2016-08-20 21:08             ` Jakub Narębski
2016-08-22 12:43               ` Duy Nguyen
2016-08-22 12:59                 ` Matthieu Moy
2016-08-22 13:09                   ` Duy Nguyen
2016-08-22 13:22                     ` Matthieu Moy
2016-08-22 13:32                       ` Duy Nguyen
2016-08-23 13:42                         ` Johannes Schindelin
2016-08-24  9:37                           ` Duy Nguyen
2016-08-24 12:44                             ` Jakub Narębski
2016-08-24 14:17                               ` Jeff King
2016-06-28 20:28   ` [PATCH v2 0/2] Config " Jeff King
2016-06-28 20:51     ` Matthieu Moy
2016-06-28 21:03       ` Jeff King
2016-06-29  4:09     ` Duy Nguyen
2016-06-28 22:11   ` 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=alpine.DEB.2.20.1607171003010.28832@virtualbox \
    --to=johannes.schindelin@gmx.de \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=pclouds@gmail.com \
    --cc=peff@peff.net \
    --cc=sschuberth@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.
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).