* Andreas Ericsson <ae@xxxxxx> [2008-10-30 15:06:16 +0100] > --all pushes all refs, even the non-matching ones, which is very > rarely desirable and only accidentally sometimes the same as "push all > matching refs". > >> I know that I've never had the intent to push all the refs without >> thinking about it first. Most of the time, I intend to push only >> the current branch I am in. > > Then say so. There's a very simple command syntax for it: > "git push <remote> <current-branch>" I update the branches I'm working in maybe 20 times a day, sometimes more. When I make a change and all the tests pass, I prefer to call git push rather than git push origin 2.0-beta1 (and "2.0-beta1" is a short name here, some branches have much longer names) I think it would be better to have : git push <= push the current branch git push --all <= push all matching refs git push --all --create <= push all matching refs, create if needed The latest command is probably used so rarely (compared to the others) that it wouldn't be a problem to make it longer. Of course, if a refspec is given explicitely, it should be honored and remote refs created if needed. I am curious of what other people workflows are. Do you often push multiple branches at the same time? More often than one at a time? Many times a day? > "git pull" is actually only vaguely connected with "git push". The > opposite of "push" is "fetch" in git lingo. I know, but "git fetch" only updates remote tracking branches, and I think that in the majority of the cases you want to advance all the remote references. And even if you screw up, the problem will only happen in your local copy, not in an upstream or shared repository. I assume that most people "push" to public repositories and not many of them "pull" into public repositories directly. -- 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
