Shallow cloning can create pull requests with one million commits

[marc-hb]

Summary: the gap left when shallow cloning can cause git merge-base to report a totally wrong merge base. This wrong merge base makes the pull request look like it's submitting all git commits since the start of the project.

Experienced in failing https://travis-ci.org/github/thesofproject/linux/jobs/740309392, https://travis-ci.org/github/thesofproject/linux/jobs/739977895 and others.

Bug announced in #2547 and tentative #2543

Cc: @kv2019i , @plbossart , @ranj063 , @xiulipan

Plug'n'play reproduction with the 100-lines long shallow_backfire.sh script. This reproduction script is purely made of git commands only: no github, no Travis,...

# After git clone --depth 20 target_branch :


# I----------------------------------> upstream 
# grafted \ 
# \ 
# \ 
# \ frequent "back merges" 
# \ 
# \ 
# \ 
# v 
# I-------------> target branch 
# grafted 



# After git fetch pull_request :


# Spurious 
# pull request 
# merge base 
# --------- I----------------------------------> upstream 
# \ grafted \ \ 
# \ \ \ 
# \ \ \ 
# 1 million \ \ \
# commits! \ \ \ 
# \ \ Actual \ 
# \ \ pull request \ 
# v v merge base v 
# -------------------------------------------- I-------------> target branch
# \ grafted 
# \ 
# \ 
# - pull_request 

# ASCII art made with the excellent textik.com

cc:

• https://stackoverflow.com/questions/25071579/list-all-files-changed-in-a-pull-request-in-git-github

[keyonjie]

@marc-hb this should be reported on the CI repo?

[marc-hb]

Not sure what the "CI repo" is. I removed "CI" from the title. Anyone or anything using shallow clones is affected, not just CI.

Only Linux is affected because other repos use git in much simpler ways.

It's probably not a bug, just a strange but probably intended git fetch behaviour/limitation.

Maybe there's some magit git fetch option to workaround this issue?

[keyonjie]

@marc-hb I change this to P3 as it is not our driver related or at least nobody is actually looking into it, feel free to change it if needed.

[marc-hb]

No, problem it was not P1 or P2 either :-)

One possible fix: fetching the PR commits directly:
https://docs.github.com/en/rest/reference/pulls#list-commits-on-a-pull-request

Github now allows fetching SHA1s directly , see zephyrproject-rtos/west#475 and https://git-scm.com/docs/git-fetch-pack