Sam Ravnborg <[EMAIL PROTECTED]> writes:

>> I would use a neutral commit template, only that it should have a
>> neutral prefix as well for the lines to be removed (neither STG nor CG
>> but GIT maybe). The $GIT_DIR/commit-template is fine as a file name.
> How about $GIT_DIR/commit-template-`basename $EDITOR`
> Then we could have different templates for vim, emacs, kade etc.

This brings up a point I have been wanting to see discussed,
involving the core people and the Porcelain people [*1*].

I would like to see Porcelains stay compatible when the do not
have to differ.  The commit template [*2*] is one example of
such.  Another example is the "dontdiff/ignore" file Pasky
talked about in a recent commit log in his Cogito tree [*3*].

Porcelains need to agree on what is placed where and used in
what way.

First, I will talk about the "what" part.  I can see there are
various "preference" items we may want to use:

  - commit template (to enforce a certain style)
  - standard "dontdiff/ignore" file.
  - pre-commit hook (to enforce a certain tests to pass)
  - post-commit-hook (sending commit-notification perhaps).
  - environment overrides (COMMITTER_NAME, COMMITTER_EMAIL and

There may be others.  Many of them would have different origin:

  - Per project.  A project may want to enforce pre-commit hook
    for all participants;

  - 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.

Personally, given the nature of GIT being a distributed system,
I do not think something like /etc/git.conf (which suggests "per
system" configuration) makes much sense; except working around a
mailhost name configuration, perhaps.

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.

  - Use $GIT_DIR/conf/ as a convention to store per repository
    configuration files.  This does not propagate with
    pulls/pushes/merges across repositories.

  - 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.

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.


*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.

*3* .gitignore in the cwd is used in Cogito, if I am not

*4* E.g. I would commit for GIT project with [EMAIL PROTECTED]
while using [EMAIL PROTECTED] for my day-job projects.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at

Reply via email to