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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html