git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v2 10/12] t5520: failing test for pull --all with no configured upstream

From
Paul Tan <pyokagan@gmail.com>
Date
May 7, 2015, 18:05 UTC
Message-ID
<CACRoPnRXJOxUkT5sKQf2bLnWVQ-+xFPu8D2PbX2b_9XVEGwQnA@mail.gmail.com>
In-Reply-To
<xmqq3838qoeb.fsf@gitster.dls.corp.google.com>
Hi,
On Fri, May 8, 2015 at 1:38 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 19 quoted lines
> Paul Tan <pyokagan@gmail.com> writes:
>
>> error_on_no_merge_candidates() does not consider the case where "$#"
>> includes command-line flags that are passed to git-fetch.
>>
>> As such, when the current branch has no configured upstream, and there
>> are no merge candidates because of that, git-pull --all erroneously reports
>> that we are pulling from "--all", as it believes that the first argument
>> is the remote name.
>
> Interesting.
>
> I do not think "pull [origin] --all" makes much sense for the same
> reason why we error out when you say "pull [origin] --tag", so I am
> not sure "There is no tracking information" is the right diag we
> would want to give the user, but I agree that "--all" is not a
> remote name.
>
> Does the same comment as 11/12 applies to this as well?

This is actually only just one symptom of the problem of git-pull assuming in many places that "$1" is the remote. There are other possible ones, such as git pull --rebase failing silently at finding the upstream branch to pass to git-rebase when git-fetch flags are passed as well (see git-pull.sh:253), though crafting a test case for that would be a bit more involved. Maybe if I have extra time to look into it.

Then there is the problem where command line flag parsing stops when an unidentified flag is encountered, assuming that it is for git-fetch. E.g. git-pull --all --dry-run will pass --dry-run to git-fetch, but will still run git-merge. Now, I haven't written this up as a test case yet because I haven't the time yet, and it could be argued that this is expected behavior, as the git-pull docs say that options meant for git-fetch must come after git-pull.

However, this is ultimately really confusing for end-users, so I propose that we just drop the distinction between git-pull's flags and git-fetch's flags, and just parse them all at git-pull. This can be done with the current git-pull.sh, but would be easier with the superior C parse-options API.

Thanks, Paul

Previous: Junio C HamanoNext: Junio C Hamano
Message 34 of 49 in “Improve git-pull test coverage”
  1. 00/12 Improve git-pull test coveragePaul Tan, May 7, 2015
  2. 01/12 t5520: implement tests for no merge candidates casesPaul Tan, May 7, 2015
  3. Torsten BögershausenMay 7, 2015
  4. Junio C HamanoMay 7, 2015
  5. Paul TanMay 7, 2015
  6. Junio C HamanoMay 7, 2015
  7. Torsten BögershausenMay 7, 2015
  8. 02/12 t5520: test for failure if index has unresolved entriesPaul Tan, May 7, 2015
  9. Eric SunshineMay 7, 2015
  10. Paul TanMay 12, 2015
  11. 03/12 t5520: test work tree fast-forward when fetch updates headPaul Tan, May 7, 2015
  12. Stefan BellerMay 7, 2015
  13. Junio C HamanoMay 7, 2015
  14. Paul TanMay 7, 2015
  15. 04/12 t5520: test --rebase with multiple branchesPaul Tan, May 7, 2015
  16. 05/12 t5520: test --rebase failure on unborn branch with indexPaul Tan, May 7, 2015
  17. Stefan BellerMay 7, 2015
  18. Paul TanMay 7, 2015
  19. Eric SunshineMay 7, 2015
  20. 06/12 t5521: test --dry-run does not make any changesPaul Tan, May 7, 2015
  21. 07/12 t4013: call git-merge instead of git-pullPaul Tan, May 7, 2015
  22. Johannes SchindelinMay 7, 2015
  23. Paul TanMay 7, 2015
  24. Johannes SchindelinMay 8, 2015
  25. Junio C HamanoMay 7, 2015
  26. 08/12 t5520: ensure origin refs are updatedPaul Tan, May 7, 2015
  27. 09/12 t7406: use "git pull" instead of "git pull --rebase"Paul Tan, May 7, 2015
  28. Junio C HamanoMay 7, 2015
  29. Paul TanMay 7, 2015
  30. Junio C HamanoMay 7, 2015
  31. Paul TanMay 10, 2015
  32. 10/12 t5520: failing test for pull --all with no configured upstreamPaul Tan, May 7, 2015
  33. Junio C HamanoMay 7, 2015
  34. Paul TanMay 7, 2015
  35. Junio C HamanoMay 7, 2015
  36. Paul TanMay 9, 2015
  37. 11/12 t5524: test --log=1 limits shortlog lengthPaul Tan, May 7, 2015
  38. Johannes SchindelinMay 7, 2015
  39. Paul TanMay 7, 2015
  40. Johannes SixtMay 7, 2015
  41. Johannes SchindelinMay 8, 2015
  42. Thomas GummererMay 8, 2015
  43. Johannes SchindelinMay 8, 2015
  44. Johannes SixtMay 8, 2015
  45. Junio C HamanoMay 8, 2015
  46. Junio C HamanoMay 7, 2015
  47. 12/12 t5520: check reflog action in fast-forward mergePaul Tan, May 7, 2015
  48. Stefan BellerMay 7, 2015
  49. Junio C HamanoMay 7, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.