"current" means: push the current branch into a remote branch with the same name, no matter what.

"upstream" means: push the current branch into the upstream branch, that is the remote branch from which you pull the current branch.

"simple" means: push the current branch into the remote branch from which you are pulling, but only if they have the same name. This is supposed to be "more safe" for beginners than the "upstream" mode.

edit: yes. http://stackoverflow.com/questions/10002239/difference-betwe...

"Tracking means that a local branch has its upstream set to a remote branch."

edit two: second question. does 'simple' mean the same as 'upstream' as long as the upstream branch (the one you are tracking from) has the same name as your local branch? I believe so but thought I'd double check.

I have been using git for 4 years. I like it a lot more than svn. I never rebase. I still don't understand some of the things, like why they call it upstream, 'the branch you are pulling from', and tracking, when to me they all seem to mean the same thing.

   1. Clone library's master branch, begin using software.
   2. Discover problem and commit a fix.
   3. Use the Github webui to create a fork of the original repo.
   4. git remote rename origin upstream
   5. git remote add origin https://github.com/me/awesome-library
   6. git push origin master:my-bug-fix
   7. Use Github webui to create a pull request from your 
      my-bug-fix branch into the upstream master.

If it were called your "intuitive" name ("current", meaning "this is the current default"), then it would, extremely unintuitively, require renaming if it ever stopped being the default. You would be sacrificing future coherence for the sake of some very mild "intuitive sense" during the present.

Complaining about git's standard porcelain is a popular sport, but so often the people who play it don't give proposals that make more sense than the status quo.

This is a classic case where the git behavior seems not just unintuitive, but far more complicated than necessary. Why do multiple modes even exist? If I were starting, I'd consider saying that "git push" with no other arguments is the same as what "current" (or even "simple") do now, but you could specify any number of branches or branch wildcards with an argument (including "*"). That is, like ls(1).

I could definitely be missing some important class of use cases, but this feels so much simpler than even having modes, let alone modes that have complex semantics, and still lets the default (very common) case work and supports pushing a manually-specified set of branches, too.

       push.default
           Defines the action git push should take if no refspec is given on
           the command line, no refspec is configured in the remote, and no
           refspec is implied by any of the options given on the command line.
           Possible values are:

           ·    nothing - do not push anything.

           ·    matching - push all matching branches. All branches having the
               same name in both ends are considered to be matching. This is
               the default.

           ·    upstream - push the current branch to its upstream branch.

           ·    tracking - deprecated synonym for upstream.

           ·    current - push the current branch to a branch of the same
               name.

Emphasis on: "if no refspec is given on the command line, no refspec is configured in the remote, and no refspec is implied by any of the options given on the command line"

These modes define what happens if you give no options to git-push. If these modes didn't exist, then you would instead be complaining that a plain old `git push` with no arguments didn't "do what you clearly meant" (where "clearly meant" changes from user to user... particularly since different users have different workflows, some centralized, some not.)

If git-push worked as you suggest, then you would just be complaining that you had to escape your asterisks characters to prevent the shell from expanding them (remember that glob expansion is not something that ls provides...), instead of using a far simpler --all.

You want a legitimate complaint about git-push? Try: "git-add allows either --all or -A, but git-push only allows --all."

On the other hand, apparently that meaning isn't actually as clear as I'd have guessed, so maybe my intuitions about intuitiveness are off-base.

That said, I disagree with the sentiment, since there is already a 'current' mode to which the 'current' name seems to apply at least equally well.