Use shallow git fetch with the same depth as the git clone

[pbartolome]

Pull request to address the issue travis-ci/travis-ci#6183

[BanzaiMan]

This looks good. We can test it later this week on staging. https://staging.travis-ci.org/

[BanzaiMan]

This has been deployed to staging.

[BanzaiMan]

This fails.

https://staging.travis-ci.org/BanzaiMan/travis_staging_test/builds/505876#L117-L118

$ git fetch --depth=50 origin +refs/pull/32/merge:
fatal: git fetch-pack: expected shallow list

[BanzaiMan]

The command's failure seems a bit unpredictable (for my test repository, anyway). It succeeds when given certain depths, but not always.

travis@a1c334e0dcb4:~$ git clone --depth=50 https://github.com/BanzaiMan/travis_staging_test.git BanzaiMan/travis_staging_test                                                    
Cloning into 'BanzaiMan/travis_staging_test'...
remote: Counting objects: 194, done.
remote: Compressing objects: 100% (91/91), done.
remote: Total 194 (delta 103), reused 185 (delta 96), pack-reused 0
Receiving objects: 100% (194/194), 23.85 KiB | 0 bytes/s, done.
Resolving deltas: 100% (103/103), done.
Checking connectivity... done.
travis@a1c334e0dcb4:~$ cd BanzaiMan/travis_staging_test/
travis@a1c334e0dcb4:~/BanzaiMan/travis_staging_test$ git fetch --depth=50 origin +refs/pull/32/merge:
fatal: git fetch-pack: expected shallow list
travis@a1c334e0dcb4:~/BanzaiMan/travis_staging_test$ git fetch --depth=40 origin +refs/pull/32/merge:                                                                             
fatal: git fetch-pack: expected shallow list
travis@a1c334e0dcb4:~/BanzaiMan/travis_staging_test$ git fetch --depth=10 origin +refs/pull/32/merge:                                                                             
remote: Counting objects: 4, done.
remote: Compressing objects: 100% (1/1), done.
remote: Total 4 (delta 3), reused 4 (delta 3), pack-reused 0
Unpacking objects: 100% (4/4), done.
From https://github.com/BanzaiMan/travis_staging_test
 * branch            refs/pull/32/merge -> FETCH_HEAD

[BanzaiMan]

Unless we can guarantee that git fetch --depth=N succeeds, we cannot merge this.

[pbartolome]

According to the git documentation (https://git-scm.com/docs/git-fetch):

--depth=
Limit fetching to the specified number of commits from the tip of each remote branch history. If fetching to a shallow repository created by git clone with --depth= option (see git-clone[1]), deepen or shorten the history to the specified number of commits. Tags for the deepened commits are not fetched.

So the --depth option set in the git fetch is not doing what I would expect and it will deepen or shorten the history using the depth. I wonder if doing the fetch with --depth=1 will always work.

Even if that works, I will propose a different solution, so instead of doing a clone and a fetch of the branch, just do a shallow clone of the merge branch (available since git 1.7.10)

git clone --depth=x git@github.com:Repository/project.git --branch +refs/pull/32/merge: --single-branch Repository/project

That way this clone will be a shallow clone of the repo but only for the merge branch, and git clone is technically doing a fetch but if no branch is specified it will clone the base branch. With the --branch option you can change that branch and clone only the merge branch, which will have the code needed to test the pull request.

[filipnavara]

Unfortunately, git clone supports only branches and tags in the --branch parameter, not arbitrary references. It is still possible to achieve the same effect but you have to go out of the way to do so:

      git init Repository/project
      cd Repository/project
      git remote add origin https://github.com/Repository/project.git
      git fetch --depth 1 origin refs/pull/$(pr)/merge:pr-merged
      git checkout pr-merged