From: Junio C Hamano <gitster@pobox.com>
To: Roman Shaposhnik <rvs@sun.com>
Cc: Ping Yin <pkufranky@gmail.com>,
Avery Pennarun <apenwarr@gmail.com>,
stuart.freeman@et.gatech.edu, git@vger.kernel.org
Subject: Re: Intricacies of submodules
Date: Fri, 11 Apr 2008 22:11:52 -0700 [thread overview]
Message-ID: <7vlk3jlkrr.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <1207970038.10408.8.camel@ginkgo> (Roman Shaposhnik's message of "Fri, 11 Apr 2008 20:13:58 -0700")
Roman Shaposhnik <rvs@sun.com> writes:
> ... Contrast this with .gitconfig where policies get
> enforced right from the minute your clone operation finishes and there's
> much less opportunity for the user to shoot himself in the foot.
Why? Even if you expect .git/config in a new repository would be vanilla
(which you can't really, as crazy sysadmin can have /etc/gitconfig or
template to override what you do), $HOME/.gitconfig would be in effect the
minute you clone.
As you cannot reasonably expect that your project is the _only_ project
your cloners would use, you cannot dictate what $HOME/.gitconfig has.
A policy issue needs to be addressed at the human level anyway, so I do
not really see major difference either way. You need to trust your users
to follow the guideline at some point, and all you can do is to make it
easy for them to do so, and (optionally) verify that they are actually
following the guideline. We need to suggest an easy-to-use and robust
mechanism to allow you to do so as the BCP.
Convenience and robustness need to be considered at the same time. In
that area, I would say a custom "sane environment setup script" would be
the more flexible, as it rolls the customization and verification into one
step.
Trust goes mutual and your users need to be able to trust you, too. If
the config mechanism blindly starts reading from in-tree .gitconfig, you
can do nasty things with aliases for example. So the "sane environment
setup script" would also be a good idea in that sense, too --- the users,
perhaps only the most suspicious and untrusting kind, have a way to verify
it does not mean any harm before running it.
Don't get me wrong. I am not saying that everybody should start rolling
their own "sane environment setup script" and ship their project with it.
I am only suggesting it as a possible way to do your "policy enforcement"
without having to introduce in-tree .gitconfig, which I unfortunately see
no fundamental upsides but definite downsides (security included).
next prev parent reply other threads:[~2008-04-12 5:12 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-31 20:59 Migrating svn to git with heavy use of externals D. Stuart Freeman
2008-04-08 18:07 ` D. Stuart Freeman
2008-04-08 20:06 ` Avery Pennarun
2008-04-08 20:49 ` D. Stuart Freeman
2008-04-08 21:01 ` Avery Pennarun
2008-04-08 22:47 ` D. Stuart Freeman
2008-04-09 3:03 ` Roman Shaposhnik
2008-04-09 3:33 ` Avery Pennarun
2008-04-09 4:39 ` Roman Shaposhnik
2008-04-09 6:34 ` Avery Pennarun
2008-04-09 6:43 ` Junio C Hamano
2008-04-10 3:43 ` Intricacies of submodules [was: Migrating svn to git with heavy use of externals] Roman Shaposhnik
2008-04-10 5:53 ` Intricacies of submodules Junio C Hamano
2008-04-10 20:32 ` Roman Shaposhnik
2008-04-11 5:20 ` Junio C Hamano
2008-04-11 16:04 ` Ping Yin
2008-04-11 22:32 ` Junio C Hamano
2008-04-12 3:13 ` Roman Shaposhnik
2008-04-12 5:11 ` Junio C Hamano [this message]
2008-04-14 19:52 ` Roman Shaposhnik
2008-04-15 1:13 ` Junio C Hamano
2008-04-15 2:13 ` Ping Yin
2008-04-16 3:49 ` Roman V. Shaposhnik
2008-04-17 18:09 ` Jeremy Maitin-Shepard
2008-04-17 19:06 ` Linus Torvalds
2008-04-17 20:04 ` Junio C Hamano
[not found] ` <32541b130804181128j57d76edcsbbd5fb8d4c782ae7@mail.gmail.com>
2008-04-18 18:30 ` Avery Pennarun
2008-04-17 19:50 ` Roman V. Shaposhnik
2008-04-17 20:06 ` Martin Langhoff
2008-04-17 20:44 ` Junio C Hamano
2008-04-17 21:00 ` Sverre Rabbelier
2008-04-17 21:25 ` Martin Langhoff
2008-04-17 21:27 ` Sverre Rabbelier
2008-04-17 21:31 ` Martin Langhoff
2008-04-18 1:41 ` Ping Yin
2008-04-17 22:29 ` Dmitry Potapov
2008-04-17 22:32 ` Linus Torvalds
2008-04-18 1:48 ` Ping Yin
2008-04-18 14:02 ` Jakub Narebski
2008-04-12 3:20 ` Ping Yin
2008-04-14 19:56 ` Roman Shaposhnik
2008-04-12 4:02 ` Ping Yin
2008-04-12 5:25 ` Junio C Hamano
2008-04-12 6:26 ` Ping Yin
2008-04-10 16:07 ` Intricacies of submodules [was: Migrating svn to git with heavy use of externals] Ping Yin
2008-04-10 19:27 ` Roman Shaposhnik
2008-04-09 19:57 ` Roman Shaposhnik
2008-04-09 20:27 ` Avery Pennarun
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=7vlk3jlkrr.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=apenwarr@gmail.com \
--cc=git@vger.kernel.org \
--cc=pkufranky@gmail.com \
--cc=rvs@sun.com \
--cc=stuart.freeman@et.gatech.edu \
/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).