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