Re: Managing websites with git

[Jason Riedy <jason@acm.org>]

And Jeff King writes:
> To clarify: one should not push to the _current branch_ of a
> non-bare repo...

Ah, ok, thanks!  Issuing a warning makes sense.  I'm not sure if
denying such a push by default does...

> Doing git push $remote HEAD:branch-that-is-checked-out
> has _never_ worked without further action on $remote. Now we're warning
> about it.

It works just fine.  I suspect we have different definitions of
"works".

To me, that push updates the branch's reference.  The working
copy and index now may be out of sync, but neither the working
copy nor the index is the branch's reference.  Trying to commit
from the index correctly refuses.  The warning is a nice
reminder, but I don't see why this should be denied by default.
The user (me) hasn't lost anything, and every tool does what it
is supposed to do (from my point of view).

But I'm one of those people who has always liked the three levels
of git.  And I use them all.

(And in context: I used to update the IEEE754 group's web site by
a git push to the checked-out master, with a hook to reset
everything.  Worked just fine (and very quickly) until they shut
off shell access.  There was no need for an extra branch on the
server side.)

> If you have other specific complaints about new git behavior,
> I'm sure the list would be happy to hear about it.

I'll try to find time when I encounter another.  I'm pretty sure
that switching to denying pushes to checked-out branches is the
first one that *really* will make me change how I work.

Jason