On Sun, Feb 10, 2008 at 02:59:18PM -0800, Junio C Hamano wrote: > > ... 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. I think "irrelevant" here is in the eye of the beholder. If you are coming from the perspective of "historical behavior" then the current behavior makes sense. If you are coming from the perspective of a user who does not typically do a lot of branching, then the behavior can be surprising. And I think there is anecdotal evidence that some users _do_ find this surprising. I have personally seen it, and I think even an experienced user like Martin is finding the behavior non-intuitive. > 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 Agreed. > 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). I think the problem is that you are asking people with particular workflows to always remember to type something extra, and if they forget, you punish them by doing a potentially destructive operation (although admittedly, it is destructive only if you happen to be using "-f"). > 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. I think we already have that option (as you mentioned): "git push $there HEAD". We can make it more easily accessible (as you have proposed): "git push HEAD" (though I still have some reservations about that). But none of that changes the fact that for some people's workflows, they will _always_ have to remember to add extra magic to the command line. What I have proposed is adding a config option to make that option even more easily accessible. The only argument I have seen against that is "some users can't use other users' git setup". While this is a downside, I think this uncommon situation is outweighed by the very common situation of users using their _own_ git setups. IOW, such an option makes a tradeoff. Users helping other users must explicitly say what they mean: "git push --matching" or "git push $there HEAD". But users using their own setups can use the shorthand "git push" to do what is most useful for their workflow. And I think we should optimize for the latter case, as it is much more common. -Peff - 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
