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

From: Andreas Ericsson <ae@op5.se>
Date: Oct 30, 2008, 14:06 UTC
Message-ID: <4909BF58.9010500@op5.se>
In-Reply-To: <2008-10-30-14-52-52+trackit+sam@rfc1149.net>

Samuel Tardieu wrote:

Show 9 quoted lines

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