Re: config-file includes

[Jeff King <peff@peff.net>]

On Mon, Sep 26, 2011 at 08:45:58PM +1000, Nguyen Thai Ngoc Duy wrote:

> > You could extend this to look in refs, with something like:
> >
> >  [include]
> >  ref = meta:config
> >
> > which would resolve meta:config to a blob and examine it (i.e., it would
> > look at refs/heads/meta).
> 
> I had something similar [1], although I disregarded worktree content
> completely.

Thanks, I had totally missed that thread.

Maybe it wasn't clear from my proposal, but I intend to disregard the
worktree entirely, too. The include.path was about including stuff from
the local filesystem, not necessarily your worktree.

> One thing about this meta thing is fsck/prune must dig in
> config file in order not to accidentally remove something config file
> refers to.

It is only a connectivity problem if you put a raw sha1 in the config.
It seems much more sensible to me to use a real ref. That solves the
fsck issue, and it makes it easier to manipulate the contents using git.

> Another thing is, what if I want to exclude certain part of the included config?

  git show origin/meta:config ;# review upstream
  git checkout meta origin/meta
  $EDITOR config
  git commit -a -m 'tweak my config based on upstream'
  git config include.ref meta:config

  [weeks later]
  git fetch ;# oh, new config from upstream
  git log -p origin/meta@{1}...origin/meta ;# looks good to me
  git checkout meta
  git merge origin/meta

Junio raised a good point in the thread you referenced: why is this any
better than the project just shipping a "./setup-config" script that you
run (and re-run when there is an update). Two things I can think of:

  1. Carrying it in the project tree (as opposed to a separate ref) is
     annoying. It bloats your project tree, and any changes you make
     get tangled up in the changes you're making to the project itself.
     To me, they're logically separate entities.

     You can still keep a separate "meta" ref that has the setup-config
     script in it, though. That wouldn't need git support at all.
     But...

  2. Using a script to deploy the config makes it annoying to track
     changes. If I make local tweaks to what upstream suggests for the
     config, I would want those tracked by git. And when upstream makes
     a change, I want to do a 3-way merge. So either my script must be
     clever in deploying, or I must never touch the deployed .git/config
     file, and instead edit the setup-config script. Even then, how does
     it handle changes in .git/config that happen naturally (e.g.,
     branch config written by git).

If we had even a mechanism to include regular files, you could do
something like:

       # make our local tweaked version of config
       git checkout meta
       $EDITOR config
       git commit -a -m 'tweak config based on upstream'

       # now deploy it
       cp config .git/tracked-config

       # and reference it
       git config include.path tracked-config

       # Weeks later, update and redeploy. Don't touch tracked-config in
       # the meantime, as your changes will be overwritten (or copy it
       # back after checkout, commit changes, then pull)
       git checkout meta
       git pull
       cp config .git/tracked-config

which is really quite similar to the "include.ref" I showed earlier,
except you can skip the annoying "deploy" step. Which is a minor
convenience if you are actually keeping your own local config branch,
and a slightly larger one if you want to do the dangerous "just look at
origin/meta for config" thing.

> > [1] I want conditional inclusion because sometimes the rules for config
> >    entries changes from version to version. For example, I have
> >    pager.diff set to a script in my ~/.gitconfig. But older versions of
> >    git don't understand non-boolean values and barf. I'd really like to
> >    do something like:
> >
> >    [include-ifdef "has-pager-scripts"]
> >    path = ~/.gitconfig-pager
> >
> >    where "has-pager-scripts" would be a magic flag compiled into git
> >    versions that understand that config.
> 
> But how far would you go with conditional expressions?

I agree it could become hairy in the general case. That's why I called
it "include-ifdef" and not "include-if". That would serve my use case. I
have no desire to support

  [include-if "2 + 2 >= 4"]

-Peff