Kaartic Sivaraam <kaarticsivaraam91196@xxxxxxxxx> 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).
