Thread (2 messages) flat view 2 messages, 2 authors, 2016-06-15

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

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:45:43

"Leo Razoumov" [off-list ref] writes:
On 11/8/08, Jeff King [off-list ref] wrote:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help