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

[Junio C Hamano]

Kaartic Sivaraam  writes:

> 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."

Yes.

> 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!"

Yes, that is why we try to be extra cautious when adding new things.

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

[Kaartic Sivaraam]

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

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

[Junio C Hamano]

Kaartic Sivaraam  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.  

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 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 the
request, 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).

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

[Kaartic Sivaraam]

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.

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?
Is it ok to proceed with the removal?

BTW, It's now clear  to me that removing '--set-upstream' has nothing
to do with merging the two parameter of 'validate_new_branchname'.

-- 
Kaartic