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

[Petr Baudis <pasky@suse.cz>]

Dear diary, on Fri, Jul 22, 2005 at 10:39:06PM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> 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 junkio@cox.net
> while using junio@twinsun.com 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