patcht3200-branch.sh: use "--set-upstream-to" in test

Change deprecated "--set-upstream" branch option to preferred "--set-upstream-to".

Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca>

---

  i'm assuming this should use "--set-upstream-to" as do all the
others.

I don't think so, see 52668846ea (builtin/branch: stop supporting the "--set-upstream" option, 2017-08-17).

Though arguably the test name could be more descriptive and tell why it should fail.

On Tue, 5 Jun 2018, SZEDER Gábor wrote:

  yes, you're right, i didn't look at the context enough. my bad.

rday

On Tuesday 05 June 2018 04:54 PM, SZEDER Gábor wrote:

That's arguable, indeed. I was about to send a patch that gives a better description for the test. I didn't do it as I started wondering, Is it even worth testing whether a removed option fails? Is this done for other options that have been removed in the past? Should we just remove the test completely?

Support for the --set-upstream option was removed in 52668846ea (builtin/branch: stop supporting the "--set-upstream" option, 2017-08-17). The change did not completely remove the command due to an issue noted in the commit's log message.

So, a test was added to ensure that a command which uses the '--set-upstream' option fails and doesn't silently act as an alias for the '--set-upstream-to' option due to option parsing features.

To avoid confusion, clarify that the option is an unsupported one in the corresponding test description.

Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
---
 t/t3200-branch.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Kaartic Sivaraam <kaartic.sivaraam@gmail.com> writes:

The above description is much clearer than what the test title after the patch gives its readers.

It is technically correct to call --set-upstream "unsupported", but the reason why we want to see it fail is not because it is unsupported, but because we actively interfere with the usual "unique prefix" logic parse-options API gives its users and make it not to trigger the longer-and-unique --set-upstream-to logic.

In other words, I am wondering if s/unsupported/disabled/ makes it even more clear what is going on here.

On Thursday 14 June 2018 11:13 PM, Junio C Hamano wrote:

That sounds right.

I guess it would :-) Thanks for the better wording. I actually thought of asking for a better wording for the test message while sending the patch but somehow forgot to mention it. It seems I've got better wordings, regardless.

I'll send a v2 with the correction. I'm still open to an alternative test description in case that make things even more clearer :-)

Thanks, Sivaraam

QUOTE:

“The three principal virtues of a programmer are Laziness, Impatience, and Hubris.”

	- Camel book

Sivaraam?

You possibly might have noticed that my signature recently changed from 'Kaartic' to 'Sivaraam' both of which are parts of my name. I find the new signature to be better for several reasons one of which is that the former signature has a lot of ambiguities in the place I live as it is a common name (NOTE: it's not a common spelling, just a common name). So, I switched signatures before it's too late.

That said, I won't mind you calling me 'Kaartic' if you like it [of course ;-)]. You can always call me using either of the names.

KIND NOTE TO THE NATIVE ENGLISH SPEAKER:

As I'm not a native English speaker myself, there might be mistaeks in my usage of English. I apologise for any mistakes that I make.

It would be "helpful" if you take the time to point out the mistakes.

It would be "super helpful" if you could provide suggestions about how to correct those mistakes.

Thanks in advance!

Support for the --set-upstream option was removed in 52668846ea (builtin/branch: stop supporting the "--set-upstream" option, 2017-08-17). The change did not completely remove the command due to an issue noted in the commit's log message.

So, a test was added to ensure that a command which uses the '--set-upstream' option fails instead of silently acting as an alias for the '--set-upstream-to' option due to option parsing features.

To avoid confusion, clarify that the option is disabled intentionally in the corresponding test description.

The test is expected to be around as long as we intentionally fail on seeing the '--set-upstream' option which in turn we expect to do for a period of time after which we can be sure that existing users of '--set-upstream' are aware that the option is no longer supported.

Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com>
---
Changes since v1:

	- update the test description as suggested by Junio

	- updated the commit message to be clear about period upto
	  which we should be testing this.

 t/t3200-branch.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)