git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Jeremy Rosen <jeremy.rosen@openwide.fr>
Cc: Git List <git@vger.kernel.org>
Subject: Re: Setting per-repository configuration for git
Date: Fri, 25 Oct 2013 04:25:13 -0400	[thread overview]
Message-ID: <20131025082513.GE17029@sigill.intra.peff.net> (raw)
In-Reply-To: <834511791.9670586.1382685155770.JavaMail.root@openwide.fr>

On Fri, Oct 25, 2013 at 09:12:35AM +0200, Jeremy Rosen wrote:

> however I can't find a way to have the repository's configuration 
> saved and transmited with the repository in a way similar to how
> .gitignore is transmitted...
> [...]
> Knowing how mature git is I can only assume that this has already
> been discussed and that there is a good reason not to do it. Is it
> because of hooks ? would it break something I don't see in git ?

There are a few reasons.

One, there are security implications.  You can execute arbitrary code
using git config options (e.g., by defining diff helpers). While it's
true that you often run the code that you fetch into your git
repository, you at least have an opportunity to verify it using git
commands before it is run.

Two, the config is not really tied to a specific revision in the same
way that a .gitignore is. If I move to another branch, or checkout an
old revision, I would want to use the .gitignore from the currently
checked-out commit. But git config does not typically work that way. If
I am sight-seeing back to last year's history, I do not want to use a
different remote URL, or different diff settings, etc. So managing a
.gitconfig directly in the repository has some ugly edge cases.

I have proposed in the past letting config includes access git objects
directly. Then a project could ship dedicated config in the "config"
branch, and you would always use the tip of that branch, even if you
were moving your working tree elsewhere in history. And if you want to
protect yourself from incoming config, you can point it to your _local_
config branch, and only merge remote changes to it after verifying they
are sane.

That would address both issues, but after some discussion, we realized
that you are really not any better off than simply pulling the data out
of git and including it as a file. So something like:

  1. Project ships recommended git config settings as `docs/gitconfig`.

  2. User clones the repo.

  3. User looks at `docs/gitconfig`, verifies that it's OK.

  4. User copies `docs/gitconfig` to `.git/project-config`.

  5. User points git at project config with `git config include.path
     project-config`.

  6. Periodically, user examines updates to `docs/gitconfig` and copies
     it to `.git/project-config`.

I don't know of any projects that do this, though, or even that ship a
recommended config. I don't know what one would put in such a config
file. Most settings are matters of personal preference, or local
configuration for the machine.

-Peff

  reply	other threads:[~2013-10-25  8:25 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <884520645.9668515.1382684531443.JavaMail.root@openwide.fr>
2013-10-25  7:12 ` Setting per-repository configuration for git Jeremy Rosen
2013-10-25  8:25   ` Jeff King [this message]
2013-10-25 12:37     ` Jakub Narebski

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=20131025082513.GE17029@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=jeremy.rosen@openwide.fr \
    /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).