On Wed, Oct 03, 2007 at 08:57:56AM +0000, Miles Bader wrote: > Pierre Habouzit writes: > > There definitely is a point: with the current behaviour you sometimes > > end up pushing more than what you meant, with sometimes WIP that you > > intend to rebase, and it hurts. Git porcelains should help you avoid to > > shoot yourself in the foot, hence I think that (especially to git > > newcomers), the current default _is_ dangerous. > > What's "dangerous" for newbies, often ends up being what doesn't > correspond with their mental model. I think the current default > behavior without any specified corresponds well to the > operation of many other git commands (and unix command) in similar > circumstances: If you don't specify something to operate on, it > essentially uses a wild card and operates on "every reasonable thing" > (e.g., consider "git commit FILE" versus "git commit"). Git commit is hardly a wildcard as it only operates on what you put in your index, which is hardly something that happens behind your back. > To the extent that a command _is_ "dangerous", there's always a tradeoff > between convenience and "danger". Some systems (e.g. those aimed at > newbies) might have as a goal to do the absolute minimum with every > command and always, always, err on the side of safety. I don't think git > is that system. I beg to differ then. I believe that "git push" default behavior is wrong. I'm not really a newbie, and it often did not do what I meant. So it could also be that there isn't a sane default either. I just say the current one can lead to gross mistakes. I know that some porcelains are risky: if you rebase "under" a point that was published you are shooting yourself in the foot e.g.. But git-rebase _is_ a command that rewrites history. You're warned from the first second you use it. But git-push is supposedly only a transport command, not something that messes with remotes history behind your back. -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org