patchAdd `-u` short option for `git pull`

>
> From: Julien Jerphanion <git@jjerphan.xyz>
>
> Add the short form `-u` as an alias for `--set-upstream`
> in `git pull`, similarly to `git push` which supports both forms.
>
> This allows users to use `git pull -u <remote> <branch>` as a
> shorter alternative to `git pull --set-upstream <remote> <branch>`.
>
> One test is included to verify that the short form works
> correctly and set the upstream configuration as expected.
>
> Signed-off-by: Julien Jerphanion <git@jjerphan.xyz>
> ---
>     Add -u short option for git pull
>
> Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-2037%2Fjjerphan%2Fpull%2Fset-upstream-short-option-v1
> Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-2037/jjerphan/pull/set-upstream-short-option-v1
> Pull-Request: https://github.com/git/git/pull/2037
>
>  builtin/pull.c          | 2 +-
>  t/t5553-set-upstream.sh | 7 +++++++
>  2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/builtin/pull.c b/builtin/pull.c
> index 5ebd5296207..e09f2963f78 100644
> --- a/builtin/pull.c
> +++ b/builtin/pull.c
> @@ -254,7 +254,7 @@ static struct option pull_options[] = {
>                 0),
>         OPT_BOOL(0, "show-forced-updates", &opt_show_forced_updates,
>                  N_("check for forced-updates on all updated branches")),
> -       OPT_PASSTHRU(0, "set-upstream", &set_upstream, NULL,
> +       OPT_PASSTHRU('u', "set-upstream", &set_upstream, NULL,

>                 N_("set upstream for git pull/fetch"),
>                 PARSE_OPT_NOARG),
>
> diff --git a/t/t5553-set-upstream.sh b/t/t5553-set-upstream.sh
> index 70e3376d31b..b4dd7c62ce9 100755
> --- a/t/t5553-set-upstream.sh
> +++ b/t/t5553-set-upstream.sh
> @@ -124,6 +124,13 @@ test_expect_success 'pull --set-upstream upstream main sets branch main but not
>         check_config_missing other
>  '
>
> +test_expect_success 'pull -u upstream main sets branch main but not other' '
> +       clear_config main other &&
> +       git pull --no-rebase -u upstream main &&
> +       check_config main upstream refs/heads/main &&
> +       check_config_missing other
> +'
> +
>  test_expect_success 'pull --set-upstream main:other2 does not set the branch other2' '
>         clear_config other2 &&
>         git pull --no-rebase --set-upstream upstream main:other2 &&
>
> base-commit: 1fa68948c3d76328236cac73d2adf33c905bd8e3
> --
> gitgitgadget
>

> From: Julien Jerphanion <git@jjerphan.xyz>
>
> Add the short form `-u` as an alias for `--set-upstream`
> in `git pull`, similarly to `git push` which supports both forms.
>
> This allows users to use `git pull -u <remote> <branch>` as a
> shorter alternative to `git pull --set-upstream <remote> <branch>`.

>  "Julien Jerphanion via GitGitGadget" <gitgitgadget@gmail.com>
>  writes:
>  
>  > From: Julien Jerphanion <git@jjerphan.xyz>
>  >
>  > Add the short form `-u` as an alias for `--set-upstream`
>  > in `git pull`, similarly to `git push` which supports both forms.
>  >
>  > This allows users to use `git pull -u <remote> <branch>` as a
>  > shorter alternative to `git pull --set-upstream <remote> <branch>`.
>  
>  The above explains what it does.  It does not justify why it is
>  needed.  Surely it may allow them to type less, but is it something
>  they would do very often, like every other day or even twice an
>  hour?  If not, should 'set-upstream' squat on a short-and-sweet 'u',
>  robbing it from future developers to use it for more useful purpose?
>  
>

> Having this shortcut would be really useful for some use cases
> where one needs to pull locally branches from forks before
> updating them and pushing them again on the fork instead than on
> the upstream project (typical use case for conda-forge's
> feedstocks).

>  Julien Jerphanion <git@jjerphan.xyz> writes:
>  
>  [jc: line-wrapped an overly long single line]
>  
>  > Having this shortcut would be really useful for some use cases
>  > where one needs to pull locally branches from forks before
>  > updating them and pushing them again on the fork instead than on
>  > the upstream project (typical use case for conda-forge's
>  > feedstocks).
>  
>  Sorry, do you mean that you stay on a single branch, and then you
>  would pull from one place with "git pull -u" followed by "git push"
>  to push back there, and repeat that for other places, practically
>  redefining the meaning of the "upstream" to "the last remote
>  repository I pulled from and I am supposed to push to that remote
>  and nowhere else in my workflow"?
>  
>