git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Leo Razoumov" <slonik.az@gmail.com>
To: "Junio C Hamano" <gitster@pobox.com>
Cc: "Jeff King" <peff@peff.net>,
	git@vger.kernel.org, "Sam Vilain" <sam@vilain.net>
Subject: Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo
Date: Mon, 1 Dec 2008 21:41:53 -0500	[thread overview]
Message-ID: <ee2a733e0812011841l73fc046dra6434340702fc282@mail.gmail.com> (raw)
In-Reply-To: <7vtz9npawn.fsf@gitster.siamese.dyndns.org>

On 12/1/08, Junio C Hamano <gitster@pobox.com> wrote:
> "Leo Razoumov" <slonik.az@gmail.com> writes:
>
>  > On 11/8/08, Jeff King <peff@peff.net> wrote:
>  >> On Fri, Nov 07, 2008 at 03:16:53PM -0800, Junio C Hamano wrote:
>  >>
>  >>  > > The FAQ even says "don't do this until you know what you are doing." So
>  >>  > > the safety valve is configurable, so that those who know what they are
>  >>  > > doing can switch it off.
>  >>  >
>  >>  > "We are breaking your existing working setup but you can add a new
>  >>  > configuration to unbreak it" should not be done lightly.  I think as the
>  >>  > end result it is a reasonable thing to aim for for this particular
>  >>  > feature, but we do need a transition plan patch in between that introduces
>  >>  > a step that warns but not forbids.  We can ship 1.6.1 with it and then
>  >>  > switch the default to forbid in 1.6.3, for example.
>  >>
>  >>
>  >> Yeah, I was kind of hoping we could assume that anybody relying on this
>  >>  behavior was somewhat insane, and wouldn't be too upset when it broke.
>  >
>  > I do not think that having a work-flow different from yours deserves a
>  > "somewhat insane" label. But let us consider the consequences of
>  > banning push into a (current branch) non-bare repo. To propagate
>  > changes to such a non-bare repo there are two remaining alternatives
>  > neither of which is fully satisfactory:
>  >
>  > (1) Switch target's current branch to something else (prevent a
>  > conflict) before pushing and then restore it back after the push
>  >
>  > (2) Use git-fetch from the target.
>
>
> (3) set the config in the target repository to allow such a push
>     regardless of the git version.
>
>  Remember, I am in the third camp in this topic myself.

Junio,
thanks for supporting the "third way". I am not sure whether I
interpret it correctly but in the same thread several message earlier
you wrote "We can ship 1.6.1 with it and then switch the default to
forbid in 1.6.3, for example". With the default set to "deny" it would
be useful if the git-push error message will indicate what config
variable to set in order to reverse the denial.

--Leo--

  reply	other threads:[~2008-12-02  2:43 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-07 22:07 [RFC PATCH 0/4] deny push to current branch of non-bare repo Jeff King
2008-11-07 22:09 ` [PATCH 1/4] t5400: expect success for denying deletion Jeff King
2008-11-09 10:38   ` Jan Krüger
2008-11-07 22:20 ` [PATCH 2/4] t5516: refactor oddball tests Jeff King
2008-11-07 22:22 ` [PATCH 3/4] tests: avoid pushing to current branch of non-bare repo Jeff King
2008-11-07 22:28 ` [PATCH 4/4] receive-pack: deny push " Jeff King
2008-11-07 22:39 ` [RFC PATCH 0/4] " Mark Burton
2008-11-07 23:16 ` Junio C Hamano
2008-11-08 14:27   ` Jeff King
2008-11-08 15:12     ` Johannes Schindelin
2008-11-08 20:49     ` Junio C Hamano
2008-11-09  1:49       ` Jeff King
2008-11-09 22:12         ` Junio C Hamano
2008-11-12  0:44         ` Kyle Moffett
2008-11-12  8:44           ` Jeff King
2008-11-13  5:22             ` Kyle Moffett
2008-11-13  5:37               ` Jeff King
2008-11-13  6:14                 ` Junio C Hamano
2008-11-13 13:58                   ` Kyle Moffett
2008-11-14  6:37                     ` Jeff King
2008-12-02  2:22     ` Leo Razoumov
2008-12-02  2:29       ` Junio C Hamano
2008-12-02  2:41         ` Leo Razoumov [this message]
2008-12-02  2:48       ` Jeff King
2008-12-02  3:08         ` Leo Razoumov

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=ee2a733e0812011841l73fc046dra6434340702fc282@mail.gmail.com \
    --to=slonik.az@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    --cc=sam@vilain.net \
    /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).