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

Re: [PATCH v2 09/12] t7406: use "git pull" instead of "git pull --rebase"

From
Junio C Hamano <gitster@pobox.com>
Date
May 7, 2015, 20:15 UTC
Message-ID
<xmqqpp6cnnyr.fsf@gitster.dls.corp.google.com>
In-Reply-To
<CACRoPnQ3zYsv63pNUtasS6y2HnWMYqwssF=yFA3OHVvF2Yb5Sw@mail.gmail.com>
Paul Tan <pyokagan@gmail.com> writes:
Show 25 quoted lines
> Hi,
>
> On Fri, May 8, 2015 at 1:24 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Paul Tan <pyokagan@gmail.com> writes:
>> If 'git pull' gets broken, it will break this test _anyway_.
>
> You have a point, perhaps this should be changed to git-fetch + git-merge?
>
> Well my reasoning is that it's because git-pull --rebase requires more
> code to be implemented than git-pull. So I'm thinking that git-pull
> --rebase is more likely to break than git-pull.
>
>> Unless
>> the operating assumption is "it is OK to break 'git pull --rebase',
>> as long as we do not break 'git pull', while rewriting it", I am not
>> sure the value of the change in this patch.  We'd need to keep both
>> form working, no?
>
> Yes, ultimately the git-pull rewrite must re-implement everything, but
> if this test suite is affected by any git-pull (--rebase) breakage,
> then there will be lots of patch noise as this test suite's tests get
> disabled/re-enabled in the git-pull rewrite patches.
>
> But if the patch noise is okay, then I'm fine with dropping this patch
> and 07/12.
I am not sure what you mean by "patch noise".

I do not think touching this test which does not have anything to do with "git pull" in your series is sensible at all, and you shouldn't flip test_expect_success temporarily to _expect_failure, if that is what you have in mind.

Just don't run unrelated tests while your series is in flux.
Previous: Paul TanNext: Paul Tan
Message 30 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.