git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: Catalin Marinas <catalin.marinas@gmail.com>,
	Petr Baudis <pasky@ucw.cz>, Linus Torvalds <torvalds@osdl.org>
Cc: git@vger.kernel.org, Bryan larsen <bryanlarsen@yahoo.com>,
	Sam Ravnborg <sam@ravnborg.org>
Subject: Re: [PATCH 1/1] Tell vim the textwidth is 75.
Date: Fri, 22 Jul 2005 13:39:06 -0700	[thread overview]
Message-ID: <7vy87yr2xh.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <20050722192424.GB8556@mars.ravnborg.org> (Sam Ravnborg's message of "Fri, 22 Jul 2005 19:24:24 +0000")

Sam Ravnborg <sam@ravnborg.org> 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
    such).

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.


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

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

*4* E.g. I would commit for GIT project with junkio@cox.net
while using junio@twinsun.com for my day-job projects.

  reply	other threads:[~2005-07-22 20:39 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-21 20:23 [PATCH 1/1] Tell vim the textwidth is 75 Bryan larsen
2005-07-22  2:50 ` Junio C Hamano
2005-07-22 10:37   ` Catalin Marinas
2005-07-22 19:24     ` Sam Ravnborg
2005-07-22 20:39       ` Junio C Hamano [this message]
2005-07-22 20:59         ` Petr Baudis
2005-07-24 22:49           ` [RFC] extending git-ls-files --exclude Junio C Hamano
2005-07-24 22:50             ` [PATCH] git-ls-files: --exclude mechanism updates Junio C Hamano
2005-07-24 22:51             ` [PATCH] Documentation: describe git-ls-files --exclude patterns Junio C Hamano
2005-07-25  9:19             ` [RFC] extending git-ls-files --exclude Catalin Marinas
2005-07-25 19:58               ` Junio C Hamano
2005-07-25 20:09                 ` Linus Torvalds
2005-07-25 20:27                   ` Junio C Hamano
2005-07-25 20:51                     ` Catalin Marinas
2005-07-28 15:57                     ` Petr Baudis
2005-07-25 20:59                 ` Catalin Marinas
2005-07-28 15:52             ` Petr Baudis
2005-07-28 16:04               ` A Large Angry SCM
2005-07-28 19:25                 ` Matthias Urlichs
2005-07-29  7:21                   ` Petr Baudis
2005-07-29  7:37                     ` Matthias Urlichs
2005-07-29 13:49                     ` A Large Angry SCM
2005-07-29  5:04               ` Junio C Hamano
2005-07-29  7:36                 ` Petr Baudis
2005-07-29  8:24                   ` Junio C Hamano
2005-07-29  8:41                     ` Petr Baudis
2005-08-01 16:14                     ` Wayne Scott
2005-07-29  7:50                 ` [PATCH] ls-files: rework exclude patterns Junio C Hamano
2005-07-29  7:51                 ` [PATCH] Documentation and tests: ls-files exclude pattern Junio C Hamano
2005-07-22 21:43         ` [PATCH 1/1] Tell vim the textwidth is 75 Catalin Marinas
2005-07-22 23:07           ` Junio C Hamano
2005-07-23  8:41             ` Catalin Marinas
2005-07-23  9:30               ` Petr Baudis
2005-07-23 10:27                 ` Catalin Marinas
2005-07-23 16:33                   ` Bryan Larsen
2005-07-23 20:52                     ` Catalin Marinas
2005-07-28 19:47                   ` Petr Baudis
2005-07-29  2:24                     ` Junio C Hamano
2005-07-29  2:59                       ` Linus Torvalds
2005-07-29  9:55                     ` Catalin Marinas
2005-07-29 11:10                       ` Petr Baudis
2005-07-29 12:34                         ` Catalin Marinas
2005-07-30  2:11                         ` Junio C Hamano
2005-07-23  9:04             ` Petr Baudis
2005-07-24  1:13               ` Junio C Hamano
2005-07-22 21:00       ` Catalin Marinas
2005-07-22 20:41     ` Petr Baudis
2005-07-22 21:16       ` Junio C Hamano
2005-07-22 21:27         ` Petr Baudis
2005-07-22 23:24           ` Junio C Hamano
2005-07-22 23:50             ` Petr Baudis
2005-07-23 10:32             ` Catalin Marinas
2005-07-26  0:18             ` Updating diff-raw status letter to 'A' for added files Junio C Hamano
2005-07-26  0:20               ` [PATCH 1/2] Use symbolic constants for diff-raw status indicators Junio C Hamano
2005-07-26  0:21               ` [PATCH 2/2] diff-raw: Use 'A' instead of 'N' for added files Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vy87yr2xh.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=bryanlarsen@yahoo.com \
    --cc=catalin.marinas@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=pasky@ucw.cz \
    --cc=sam@ravnborg.org \
    --cc=torvalds@osdl.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).