Jeff King <peff@xxxxxxxx> writes: > ... Are there any > other git commands which use non-HEAD branches that have not been > explicitly mentioned by the user? I can think only of query-type > commands (like show-branch, or describe) that are non-state-changing. That's an irrelevant comparison. push and fetch have always been multi-branch operations by default from day one. The issue is not HEAD vs non-HEAD. You can argue that historically established practices do not matter at all (at least to new people), and I'd grant that it may be a valid argument. But a change that breaks existing practices needs to be sold much more carefully. I still do not understand what the opposition is to keep the current behaviour as the default and have a shorthand for the single head push accessible with a short and sweet "git push $there HEAD" (and default $there to 'origin' when missing). If you are introducing a new behaviour, there is no way the new behaviour can start out by replacing the longtime default. It should start out as an option, and if it is a commonly useful option then make it an _easily accessible_ option. And accept such an _enhancement_ sooner to help people who want such a behaviour sooner. That would not hurt anybody but help (hopefully) many people, without downside. Switching the default behaviour is a much longer term thing. It definitely has downside people mentioned in this thread. - 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
