On Mon, 2017-08-07 at 13:59 -0700, Junio C Hamano wrote:
> Kaartic Sivaraam <[email protected]> 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!
> 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.
> > 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."
> 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
