> Yeah, I agree that it's not quite as turnkey if you have to assume > something about the user's directory structure. On the other hand, they > have to decide to put the included config file somewhere, too, so it > seems like you need to give the user "do something like this" > instructions rather than purely something they can copy and paste. They can copy and paste instructions to add a package repository (e.g. by editing /etc/apt/sources.list) and then install a package. > I dunno. I guess you can assume they'll put it in ~/.gitconfig-foo or > similar, and come up with copy-and-pastable directions from that. > > I agree that the "match the remote" rule makes things _more_ convenient. > Mostly I was just wondering if it changed things enough to merit the > complications it introduces. I'm not sure I have an answer, and clearly > it's pretty subjective. I am almost done with the implementation, so maybe the community could look at it and concretely see the extent of the complication. > > > Just brainstorming some alternatives: > > > > > > - We could stop the world while we are parsing and do a _new_ parse > > > that just looks at the remote config (in fact, this is the natural > > > thing if you were consulting the regular remote.c code for the list > > > of remotes, because it does its own config parse). > > > > > > That does mean that the remote-conditional includes cannot > > > themselves define new remotes. But I think that is already the case > > > with your patch (and violating that gets you into weird circular > > > problems). > > > > Hmm...yes, having a special-case rule that such an included file cannot > > define new remotes would be complex. > > I think that's mostly true of your "defer" system, too, unless you keep > applying it recursively. The rule is slightly different there: it's not > "you can't define new remotes", but rather "you can't do a > remote-conditional include based on a remote included by > remote-conditional". I was thinking that deferred includes cannot themselves have other deferred includes and that which deferred includes are included would be computed only once, and those would be the only rules. (But I guess this is moot now - we're not doing this approach.) > > > - We could simply document that if you want to depend on conditional > > > includes based on a particular remote.*.url existing, then that > > > remote config must appear earlier in the sequence. > > > > > > This is a bit ugly, because I'm sure it will bite somebody > > > eventually. But at the same time, it resolves all of the weird > > > timing issues, and does so in a way that will be easy to match if we > > > have any other config dependencies. > > > > My main issue with this is that different config files are read at > > different times, and the repo config (that usually contains the remote) > > is read last. > > Ah, right. I was thinking of the definitions within a single file, but > you're right that the common case would be having the include in > ~/.gitconfig, and the remotes defined in $GIT_DIR/config. So yeah, any > ordering constraint like that is a non-starter, I'd think. > > -Peff Yeah. Thanks for continuing to take a look at this.
