Re: [RFC - draft] List of proposed future changes that are backward incompatible

> On Sun, 15 Feb 2009, david@lang.hm wrote:
>
>> On Mon, 16 Feb 2009, Johannes Schindelin wrote:
>>
>>> On Sun, 15 Feb 2009, david@lang.hm wrote:
>>>
>>>> On Sun, 15 Feb 2009, Junio C Hamano wrote:
>>>>
>>>>> Thanks.
>>>>>
>>>>> * git-push to update the checked out branch will be refused by default
>>>>>
>>>>>  Make "git push" into a repository to update the branch that is checked
>>>>>  out fail by default.
>>>>>
>>>>>  http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007
>>>>
>>>> If I understand this one, it will cause grief for quite a few people.
>>>>
>>>> I have a public repository that I push to and then have a trigger that
>>>> checks
>>>> out the current version, compiles it, publishes the compiled version,
>>>> sends an
>>>> announcement, etc
>>>
>>> So you have to set a config variable.  Big deal.

>>> Compared to that, the thousands of new Git users will no longer be bitten
>>> by the "do not push to a non-bare repository" issue without a useful error
>>> message.
>>>
>>> Please, please, publicize that if there is somebody who is doing the same
>>> as you (which I deem a dangerous workflow; I certainly do not use it
>>> myself) that they will have to adjust their receive.denyCurrentBranch
>>> variable.
>>
>> since this repository isn't use for anything other than publishing for public
>> access, what's so dangerous about it?
>
> Hey, you do what you want...
>
> I just keep in mind that it _is_ a working directory that can go dirty,
> for whatever reasons.
>
> Which is why _I_ do things like your workflow locally, even if that means
> that I log onto another machine (which is then "local").
>
> But again, it is your choice.  And certainly, it will be possible in the
> future, too, just more deprecated than it is already.