Re: Minor annoyance with git push

[Steven Walter <stevenrwalter@gmail.com>]

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@gmail.com>
Freedom is the freedom to say that 2 + 2 = 4
B2F1 0ECC E605 7321 E818  7A65 FC81 9777 DC28 9E8F