On Sun, Aug 24, 2008 at 03:59:49PM -0700, Junio C Hamano wrote: > > Couldn't the exact opposite argument be made for "suppose you want to > > put the mail-alias file in a repo-specific directory that was not > > tracked?" I.e., you are trading off "CONTRIBUTORS" against > > ".git/CONTRIBUTORS". > > No, I couldn't ;-) > > Why would you write what you wrote in README? > > Anything you store in .git is not propagated, so the instruction would not > likely to be "store it in .git/CONTRIBUTORS and point at it". There is no > merit in forcing users to standardize on "in .git". The instruction would > be to "store it anywhere you want, and point at it". Ah, right. I still think there is a little bit of convenience when you are doing something totally personal (i.e., not putting it in a README, but rather just wanting to store the referenced file in .git for the sake of simplicity). But in that case, it is only slightly less convenient to just point to the full path. So your example trumps this, since you have no sane way of knowing the full path in README instructions. > Because we haven't deprecated core.worktree (or $GIT_WORK_TREE) yet, your > suggestion has an obvious chicken-and-egg problem, even though otherwise I > think it makes perfect sense and very much like it. You might be able to get around that by lazily filling in the variable. IOW, expand it at the point-of-use rather than while reading the config. However, the point of use might easily have something to do with reading config, so that re-creates the cycle. In general, I think we treat config as order-independent. We could make the use of such variables order-dependent (i.e., if you haven't set core.worktree, then we give you the value without having set it, and we recalculate later. Confusing results, but at least a simple rule to understand). I think there actually are a few other order-dependent things in the config, like the order of multi-value keys like push and fetch refspecs. Would you want this expansion only for specially marked variables, or for all variables? I like the concept of general templates for config values, but it will backwards compatibility, especially for alias.*. > Perhaps we should rid of the worktree that is separate and floats > unrelated to where $GIT_DIR is. I assumed people were actually using it, which is why it was implemented. -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
