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 -- 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
