"Leo Razoumov" <slonik.az@xxxxxxxxx> writes:
> 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.
(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.
--
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
