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

On Thursday, October 30, 2008 at 16:25:50 (+0100) Andreas Ericsson writes:

Samuel Tardieu wrote:

quoted

* Andreas Ericsson [off-list ref] [2008-10-30 15:54:53 +0100]

quoted

Correct me if I'm wrong, but wouldn't my suggestion of not trying to
push (even matching) branches that haven't been updated since we last
fetched from the remote do exactly the same thing for your particular
use-case, but without syntax change and all the annoying minor parts
that it entails?

Not exactly. I often do some work on a branch which does not mandate
a topic branch and have to switch branches to fix a bug for example.
This would continue to push unterminated changes as well.

Typical use case, which happens (to me) quite frequently:

...

quoted

Argh, "master" has been pushed as well. Ok, I could have done

Ah, I see. I sympathize, although I really do think you'd be
better off by learning to explicitly push things.

Exactly my concerns when I raised this issue originally.  It's hard to
teach people to do this:

% git push origin master

or:

% git pull origin master

so that when they intend and MUST do this (lest chaos ensue):

% git push origin ReleaseBranch

or this:

% git pull origin ReleaseBranch

they don't mistakenly do this:

% git push

or:

% git pull

the reason being that every manual our users read says "use git push",
use "git pull", the examples being written for 'master' branch usage,
and people just assume that 'git push'/'git pull' are smart enough to
know which branch you are on and do the same logical thing as a bare
'git push'/'git pull' does when on master.

Several times this has happened to us: people make this mistake and
push or pull stuff into a branch they do not want.  The pull is not so
bad, but the push messes up our central repo.  This has happened both
here at my current company, and my previous one, and the persons
making the mistakes are neither sloppy nor inexperienced.


Bill