Re: Using the --track option when creating a branch

[Andreas Ericsson <ae@op5.se>]

Samuel Tardieu wrote:
>>>>>> "Andreas" == Andreas Ericsson <ae@op5.se> writes:
> 
> Andreas> This particular bikeshed was painted a long time ago, with
> Andreas> the consensus going in favour of "git push" pushing all
> Andreas> *matching* refspecs.
> 
> I still don't understand why this is useful, especially when git push
> already has a "--all" option.
> 

--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>"

> The current behaviour made me remove the branches I was not actively
> on locally, because I would get errors from "git push" all the time
> saying that I was not up-to-date in those branches.
> 

That's an orthogonal issue, and one that really could be fixed without
anyone complaining. Send a patch that checks if foo is a strict subset
of <remote>/foo before trying to send it, and abort if it is so. This
means that we'll try to push "foo" if upstream rewrote their "foo", but
perhaps that's just as well.

Note though that the patch mustn't try to apply any smarts if a ref is
given explicitly.

> Note that the "git pull" issue is completely different, as it merges
> or fast forwards the current branch only.
> 

"git pull" is actually only vaguely connected with "git push". The
opposite of "push" is "fetch" in git lingo.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231