Dear diary, on Fri, Jul 22, 2005 at 10:39:06PM CEST, I got a letter where Junio C Hamano <[EMAIL PROTECTED]> told me that... > Porcelains need to agree on what is placed where and used in > what way.
Yes, I always try to make things as Cogito-unspecific as possible. > - Per user. A user may want to use different environment > settings for different projects [*4*]. > > - Per repository (or work tree). A user may have more than > one work tree for the same project, and want to use > different "preference" items per tree. I wouldn't distinct between those two. You as a user can copy things around when you clone the repositories (if you ever do so), or the Porcelain can do it, but having global per-user _combined with per-project settings sounds nightmarish. After all, how do you identify a project? What if projects merge? I wouldn't open this can of worms. Obviously, there have to be just per-user settings (independent of "project"). > About the "where" part, one proposal I have off the top of my > head is something like this: > > - Have a directory at the root of the tree, "_git" (I do not > care about the name at this moment. The point being it can > be revision controlled as part of the project and propagate > to other repositories), to store per-project configuration. Fine, but I would probably prefer having it hidden. .gitinfo? > - Use $GIT_DIR/conf/ as a convention to store per repository > configuration files. This does not propagate with > pulls/pushes/merges across repositories. That's fine by me. I'd prefer the hooks staying in $GIT_DIR/hooks/. > - Use $HOME/.gitrc (could be a directory or a file in .ini > style like StGIT uses -- again, I do not care about the > details at this moment) to store per-user configuration. As long as I can sanely parse it in shell... ;-) > Which configuration is read first, what can be overridden, and > if the configuration is cumulative would be specific to each > preference item, I suspect. Some project may not want a user to > override the pre-commit hooks, for a bad example. But normally > the per-repository one would take precedence over per-user one > which in turn would take precedence over per-project one. What about just running all the hooks in the order you specified? > [Footnotes] > > *1* Technically this does not involve the core at all, but the > core people can act as objective, Porcelain-neutral referees. > They'll need to know the outcome of the discussion anyway, since > they are the ones that end up maintaining the Porcelain-neutral > tutorial document. > > *2* Unless we are talking about the kind that shows and lets you > edit the diff to be committed, which somebody else's Porcelain > may support, that is. FWIW, I'm planning something like this in cg-commit (when called explicitly with -d) in short-term future. > *3* .gitignore in the cwd is used in Cogito, if I am not > mistaken. Yes. There were several discussions about this in the past, with no clear outcome, IIRC. I would prefer: ~/.git/ignore per-user /.git/ignore per-repository .gitignore per-directory (cummulative with parent directories) Note that I also want to make use of some special characters in this file. In particular /^# and /^!, to make it at least as powerful as CVS' ignore. > *4* E.g. I would commit for GIT project with [EMAIL PROTECTED] > while using [EMAIL PROTECTED] for my day-job projects. .git/author in current Cogito (.git/conf/author or something in the Brave New World ;-). -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html