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

Re: [PATCH 2/7] t5520: implement tests for no merge candidates cases

From
Paul Tan <pyokagan@gmail.com>
Date
May 6, 2015, 06:04 UTC
Message-ID
<CACRoPnQ5EaCmO-tmDxmNW_snFLbFNOq06wdF_p4FPHHv+HiJBA@mail.gmail.com>
In-Reply-To
<vpqvbg8u5sq.fsf@anie.imag.fr>
Hi,

On Mon, May 4, 2015 at 4:04 PM, Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> wrote:

Show 16 quoted lines
> Paul Tan <pyokagan@gmail.com> writes:
>> I'm having trouble hitting the 1st case without resorting to the hack below. A
>> detached HEAD will always have no remote configured, and the code flow would
>> make it such that case (4) is hit in the detached HEAD case instead of case
>> (1).
>
> This should appear in comments in the test 'fail if not on a branch'.
> People reading your [branch ""] in the future won't look for
> below-triple-dash comments in the mailing-list archives ...
>
> And actually, it would be more user-friendly to trigger this error
> message in the normal senario, i.e. check for 1. before 4. in the code.
> This was most likely the intension of the programmer who wrote this
> error message. You may want to fix this now, or add a
> test_expect_failure which will become a test_expect_success when you
> replace git-pull.sh with builtin/pull.c.

Ah, I just figured out how to trigger this error. Just for reference, before I forget:

1. HEAD must be detached (such that there is no configured remote)
2. The default remote "origin" must exist, so that git-fetch will
succeed even though there is no configured remote for the detached
HEAD.
3. git pull must be called with no arguments, to avoid (4).

I guess everything is working as intended. I copied the different cases from the commit message of a8c9bef4, but I think that they should be re-ordered to match the logic in the code. Furthermore, cases (1) and (2) could probably be explained as:

(1) git-fetch succeeded in fetching from the branch's or repo's default remote, but:

(1a) We are not on a branch, so there will never be a configured upstream branch to merge with.

(1b) We are on a branch, but there is no configured upstream branch to merge with.

Previous: Matthieu MoyNext: Paul Tan
Message 5 of 21 in “Improve git-pull test coverage”
  1. 0/7 Improve git-pull test coveragePaul Tan, May 2, 2015
  2. 1/7 t5520: test pulling multiple branches into an empty repositoryPaul Tan, May 2, 2015
  3. 2/7 t5520: implement tests for no merge candidates casesPaul Tan, May 2, 2015
  4. Matthieu MoyMay 4, 2015
  5. Paul TanMay 6, 2015
  6. Paul TanMay 6, 2015
  7. 3/7 t5520: test for failure if index has unresolved entriesPaul Tan, May 2, 2015
  8. Matthieu MoyMay 4, 2015
  9. 4/7 t5520: test work tree fast-forward when fetch updates headPaul Tan, May 2, 2015
  10. Eric SunshineMay 3, 2015
  11. Paul TanMay 3, 2015
  12. 5/7 t5520: test --rebase with multiple branchesPaul Tan, May 2, 2015
  13. Stefan BellerMay 4, 2015
  14. Junio C HamanoMay 4, 2015
  15. Paul TanMay 5, 2015
  16. 6/7 t5520: test --rebase failure on unborn branch with indexPaul Tan, May 2, 2015
  17. 7/7 t5521: test --dry-run does not make any changesPaul Tan, May 2, 2015
  18. Matthieu MoyMay 4, 2015
  19. Junio C HamanoMay 4, 2015
  20. Paul TanMay 5, 2015
  21. Paul TanMay 6, 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.