Re: Can the '--set-upstream' option of branch be removed ?

From: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com>
Date: Aug 8, 2017, 13:00 UTC
Message-ID: <1502197230.2071.3.camel@gmail.com>
In-Reply-To: <xmqq60dzp00l.fsf@gitster.mtv.corp.google.com>

On Mon, 2017-08-07 at 13:59 -0700, Junio C Hamano wrote:

Show 20 quoted lines

> Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> writes:
> 
> > I refactored builtin/branch.c to remove the '--set-upstream'
> > option,successfully. The corresponding patch follows. 
> > 
> > There's just one issue with the version of git that doesn't
> > have the '--set-upstream' option. It's described in the commit
> > log message of the following patch.
> 
> which is...
> 
> > Note that, 'git branch' still *accepts* '--set-upstream' as a consequence
> > of "unique prefix can be abbrievated in option names". '--set-upstream'
> > is a unique prefix of '--set-upstream-to' after '--set-upstream' has
> > been removed.
> 
> ... this.
> 
> Thanks for spotting the issue.  
>

Oh, I would have to thank you for enlightening me about,

    "unique prefix can be abbrievated in option names"

If I didn't know that, it would taken me some time (or an email) to find why 'git' accepted '--set-upstream' even after it's removal!

Show 5 quoted lines

> I think in the longer term we still want to remove --set-upstream as
> many people seem to say that its behaviour has been uttering
> confusing to them and that is why we keep giving the warning any
> time it is used.
>

I do accept that. The behaviour of '--set-upstream' is awkward.

Show 9 quoted lines

> > I guess it would be difficult to detect the removal of the option in
> > case it's used in scripts and might cause confusion to users?
> 
> If we want to follow through the transition, because of the issue
> you spotted, we'd need one extra step to make sure users won't be
> hurt before removal: we would need to still recognize --set-upstream
> as an option distinct from --set-upstream-to, and actively fail thes
> request, telling them that the former option no longer is supported.
>

There's no issue in doing that if people don't shout at us for the behaviour :)

Just to be sure, you mean "die() with a good message" when you say "fail these requests, telling them that the former option no longer is supported."

Show 6 quoted lines

> Then after waiting for a few years, we may be able to re-introduce
> the "--set-upstream" option that takes the arguments in the same
> order as "--set-upstream-to", which would be the ideal endgame
> (assuming that the reason why we started deprecating "--set-upstream"
> and encouraged users to use "--set-upstream-to" still holds).
>

It's pretty surprising it takes almost a decade to *stop accepting* a bad option though many users are confused by it.

"It's easier to do things than to undo them!"

-- 
Kaartic