git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / Atom feed
From: Marc Branchaud <marcnarc@xiplink.com>
To: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, Git <git@vger.kernel.org>
Subject: Re: RFC: Supporting .git/hooks/$NAME.d/* && /etc/git/hooks/$NAME.d/*
Date: Tue, 26 Apr 2016 17:09:25 -0400
Message-ID: <571FD905.6010705@xiplink.com> (raw)
In-Reply-To: <CACBZZX6CRBQ5qOBdwamqJMz+_QU-cmVfA7iLTyjOCYentjx-mw@mail.gmail.com>

On 2016-04-26 12:09 PM, Ævar Arnfjörð Bjarmason wrote:
>
> Basically you can look at patches to a project on a spectrum of:
>
>   1. You hacked something up locally
>   2. It's in someone's *.git repo as a POC
>   3. It's a third-party patch series used by a bunch of people
>   4. In an official release but documented as experimental
>   5. In an official release as a first-rate feature
>
> Something like an experimental.WHATEVER=bool flag provides #4.

But the git project already does #4 without needing a special 
configuration tree.  In fact, you ignored the git project's "pu" branch 
entirely.  Once a feature gets onto the "next" branch, it's already much 
less experimental.  If it needs to put the word "experimental" in its 
config settings, then maybe shouldn't leave the "pu" branch in the first 
place.

> I think aside from this feature just leaving these things undocumented
> really provides the worst of both worlds.

Yes, I apologize.  I did not mean that things should remain 
undocumented, only that if you're afraid of users harming themselves 
then you're better off not documenting settings than labelling them as 
experimental.

> Now you have some feature that's undocumented *because* you're not
> sure about it, but you can't ever be sure about it unless people
> actually use it, and if it's not documented at all effectively it's as
> visible as some third-party patch series. I.e. only people really
> involved in the project will ever use it.

Slapping "experimental" on the configuration only serves to muddy the 
waters.  Either the feature is good enough to be tried by normal users, 
or it isn't.  If it isn't ready for normal users, let it cook in pu (or 
next) for a while longer.

Git has got on just fine without having some special designation for 
not-ready-for-prime-time features, mostly because the development 
process lends itself naturally to gradually exposing things as they 
mature: topics move from the list to pu to next to master.  (The string 
"experiment" only appears 16 times in all the release notes, which I 
think is something the git project can be proud of.)

To me, designating part of the config tree as "experimental" enables 
sloppier practices, where a feature can be released with a bit less 
effort than might otherwise be acceptable, because it's clearly marked 
as experimental, and so anyone trying it out surely has the requisite 
bulletproof footwear.  (I don't mean to imply that you or any other git 
contributor might slack off on any work you do for the project. It's 
more that the ability to easily designate something as experimental 
lowers the bar a bit, and makes it more tempting to release 
not-quite-ready features.)

Far better to instead work on the feature until it's as ready as can be, 
and release it properly.

In this particular case, for example, I think your proposed approach is 
perfectly fine and does not need to be designated as "experimental" in 
any way.  With a reasonable "hooks.something" config variable to turn on 
directory support, what you've described sounds like a great feature. 
Sure, it may have bugs, it may have unintended consequences, it may not 
fulfill some odd corner cases.  But that's true for almost everything. 
As with every other git feature, it'll be developed to the best of the 
project's abilities and released.  Future patches are welcome.

		M.

  parent reply index

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-22 23:51 Ævar Arnfjörð Bjarmason
2016-04-25 17:45 ` Junio C Hamano
2016-04-26 10:58   ` Ævar Arnfjörð Bjarmason
2016-04-26 13:40     ` Marc Branchaud
2016-04-26 16:09       ` Ævar Arnfjörð Bjarmason
2016-04-26 17:52         ` Christian Couder
2016-04-26 21:09         ` Marc Branchaud [this message]
2016-04-26 21:52     ` 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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=571FD905.6010705@xiplink.com \
    --to=marcnarc@xiplink.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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

git@vger.kernel.org list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Example config snippet for mirrors

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git