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

Samuel Tardieu wrote:

quoted

quoted

quoted

quoted

quoted

"Andreas" == Andreas Ericsson [off-list ref] 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