On 11/8/08, Jeff King <peff@xxxxxxxx> 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. 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
