Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo

From: Leo Razoumov <slonik.az@gmail.com>
Date: Dec 2, 2008, 02:22 UTC
Message-ID: <ee2a733e0812011822r4cef6a44ra68d6e84f9e30a90@mail.gmail.com>
In-Reply-To: <20081108142756.GC17100@coredump.intra.peff.net>

On 11/8/08, Jeff King <peff@peff.net> wrote:

Show 16 quoted lines

> 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.

Method (1) is no better than what is available today with "git reset --hard" to sync working directory. Method (2) is even worse, because git-fetch provides no control of what branches/tags to fetch, it sucks everything in from all branches. "git-push", OTOH, can be instructed to be very selective.

Here is an example of such a work-flow

Foo.git -- main bare repo of the project Foo.wip -- everyday "work in progress" repo. Cloned from Foo.git. Pushes to Foo.git Foo.wip.insane -- experimental "crazy" stuff cloned from Foo.wip. Pushed to Foo.wip

Proposed patch makes this work flow impossible (cannot push from Foo.wip.insane to Foo.wip)

--Leo--