On 11/8/08, Jeff King <peff@peff.net> wrote:
quoted text
> 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--
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html