On Sun, Feb 10, 2008 at 03:03:13PM +0100, Wincent Colaiuta wrote: > I think there's no way we should be catering for people who type command > like "git push" just to see what the synopsis does. > > The verb "push" very clearly has connotations of a state-changing, possibly > irreversible action (unlike other verbs like "log" or "show"). I think you're quite correct: push is a state changing action. For that reason, it should default to the smallest amount of work conceivably envisioned by the user. To do more work than the user may have meant is asking for trouble. Take git-commit as a parallel. You make some file changes and run "git commit". Nothing happens. If you wanted to commit all your changes, you need the -a flag. Here, subversion takes the opposite approach and commits all your files, when in fact you may have only wanted a smaller subset. I have seen this cause problems many times (and more than once, I was the problem-maker :) ) > People who type "git push" just to see a synopsis need to learn a lesson; > the lesson being that if you want to find out what a command does the > safest thing is to type "git help push" instead. This is an interesting theory on user-interface design. I propose a new configuration option, remote.*.pushAllRefs, defaulting to off. When pushAllRefs is false, "git push" pushes only the current branch. When pushAllRefs is true, "git push" does what it does today. For the old-timers, the impact of such a change seems minimal. Worst-case, they run "git push," it doesn't do what they expect, they run "git push origin" and then go change their config files. Thoughts? -- -Steven Walter <stevenrwalter@xxxxxxxxx> Freedom is the freedom to say that 2 + 2 = 4 B2F1 0ECC E605 7321 E818 7A65 FC81 9777 DC28 9E8F - 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
