Re: [PATCH 1/1] Tell vim the textwidth is 75.

[Catalin Marinas <catalin.marinas@gmail.com>]

On Fri, 2005-07-22 at 13:39 -0700, Junio C Hamano wrote:
> I would like to see Porcelains stay compatible when the do not
> have to differ.  The commit template [*2*] is one example of
> such.  

For StGIT it is not a problem to use any commit template with any
prefix. It doesn't generate extra lines.

Would such a template only have 'GIT:' prefixed lines? I usually put
another line like 'Signed-off-by:', for convenience. The problem with
StGIT appears when one wants to re-edit the patch description (stg
refresh -e), in which case the existing description should be merged
with a part of the template (if you want to get the editor setting for
example). It doesn't do this since there is no point in getting another
'Signed...' line in the existing description.

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

OK

>   - standard "dontdiff/ignore" file.

StGIT currently uses .git/exclude, since I saw it used by cogito. What
is dontdiff supposed to do? The 'git diff' command only shows the diff
for the files added to the repository.

>   - pre-commit hook (to enforce a certain tests to pass)
>   - post-commit-hook (sending commit-notification perhaps).

OK

>   - environment overrides (COMMITTER_NAME, COMMITTER_EMAIL and
>     such).

StGIT works the other way around. By default uses the environment, which
can be overridden by the stgitrc file. I could change this easily.

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

As Petr said, it's hard to define a project.

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

StGIT uses /etc/stgitrc, ~/.stgitrc and .git/stgitrc, the latter
overriding the former.

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

For StGIT it makes sense to get some default settings via /etc/stgitrc.
There are things like a SMTP server and the diff3 command. These are set
when installing the application and can be overridden in your home
or .git directories.

> About the "where" part, one proposal I have off the top of my
> head is something like this:

Before we get to "where", we should define the common settings. I think
that git should define the common settings for its operations and the
other tools should follow them.

Once you get unique settings for an application (like mail templates or
three-way merge commands), it's pretty hard to put them in the same
file. It would even be confusing for users.

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

That's the thing I didn't like in GNU Arch. You modify the file ignoring
rules for example and the change will be included in the next commit.
You could only get some defaults when cloning a repository, otherwise
once you have different preferences from the repository's maintainer,
you start getting conflicts in the config files.

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

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

Again, having Porcelain specific options mixed in the same file might
lead to some confusion among users.

> But normally
> the per-repository one would take precedence over per-user one
> which in turn would take precedence over per-project one.

With a note if specifying what a project is.

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

I will to add this to StGIT.

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

In StGIT this is settable via authorname/authoremail in the stgitrc file
and can be per repository or per user.

-- 
Catalin