Junio C Hamano wrote:
GIT v1.6.4 Release Notes (draft) ================================ With the next major release, "git push" into a branch that is currently checked out will be refused by default. You can choose what should happen upon such a push by setting the configuration variable receive.denyCurrentBranch in the receiving repository. To ease the transition plan, the receiving repository of such a push running this release will issue a big warning when the configuration variable is missing. Please refer to: http://git.or.cz/gitwiki/GitFaq#non-bare http://thread.gmane.org/gmane.comp.version-control.git/107758/focus=108007 for more details on the reason why this change is needed and the transition plan. For a similar reason, "git push $there :$killed" to delete the branch $killed in a remote repository $there, if $killed branch is the current branch pointed at by its HEAD, gets a large warning. You can choose what should happen upon such a push by setting the configuration variable receive.denyDeleteCurrent in the receiving repository. When the user does not tell "git push" what to push, it has always pushed matching refs. For some people it is unexpected, and a new configuration variable push.default has been introduced to allow changing a different default behaviour. To advertise the new feature, a big warning is issued if this is not configured and a git push without arguments is attempted. Side note: we might want to tone this down, as it does not seem likely for us to change the default behaviour when this option is not set.
Is there some sort of guide to the new best practices for handling trees such as git.kernel.org, where one pushes into "foo.git" directly, and there is no checked-out source code at all?
I've been getting the multi-line "warning: Updating the currently checked out branch may cause confusion" message, but ignoring it for now, because it does not appear to apply to my situation (no checked-out work tree).
Advice appreciated... Jeff -- 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