Re: [PATCH 2/2] push: --ignore-stale option

From: Marc Branchaud <marcnarc@xiplink.com>
Date: Dec 15, 2011, 17:47 UTC
Message-ID: <4EEA329F.1020201@xiplink.com>
In-Reply-To: <20111215073816.GD1327@sigill.intra.peff.net>

On 11-12-15 02:38 AM, Jeff King wrote:

Show 26 quoted lines

> 
> But I still see this as solving the wrong problem, and encouraging a
> dangerous workflow. Why are you using ":" to push matching branches if
> you don't want to push topic1? I think a much more likely scenario is:
> 
>   $ git clone <<origin>>
>   $ git checkout -b topic1 origin/topic1
>   $ work work work
>   $ : hmm, it's not ready yet
>   $ git checkout -b topic2 origin/topic2
>   $ work work work
>   $ : looking good, let's ship it!
>   $ git push  ;# we default to matching!
> 
> I.e., the user is not actually intending to push all matching branches,
> but does so accidentally because "matching" is the default. And they
> have accidentally just pushed non-ready work to topic1, which would
> happen even with --ignore-stale.
> 
> IOW, I am not convinced that people are actually consciously choosing
> the workflow you outlined above, and are instead interested in
> --ignore-stale as a convenient way of guessing which branches should be
> pushed during a matching push. But it's only a guess, and as I showed
> above, it can still cause problems. I think the right solution is to
> switch the default away from matching, which is the root cause of the
> confusion.

100% agree.

In my experience, people are confused by any magic that happens when a local
ref name matches a remote's ref name.  I find folks have a much easier time
with git once they embrace the notion that a remote's branches are distinct
from their local clone's, and that explicitly saying
	push origin <local>:<remote>
is the clearest way of making sure git does what you want.

It's convenient for advanced users to take advantage of the shortcuts any ref-matching magic provides, but I find novice users tend to make mistakes as often as not.

M.