Home > Blockchain >  git merge-base with sparse checkout and --no-tags
git merge-base with sparse checkout and --no-tags

Time:12-16

I have a script running on a git repository which does some analysis prior to merging a pull request.

The script performs

git merge-base master HEAD

to determine the "deviation point" commit.

However, the local git repo was formed using a sparse checkout in a Jenkins workspace and this configuration cannot be changed. It is obtained via:

  • git init
  • then a few git fetch --no-tags
  • git config core.sparsecheckout
  • git checkout -f <hash>

Then there is the following error:

fatal: Not a valid object name master

The output of git log looks like this:

commit 84887... (HEAD, origin/PR-424)
Author: Me
Date:   Today

    blah blah

commit 54adf...
Merge: 889aefe 46630ae
Author: Me
Date:   Yesterday

    Merge pull request #123 in blah blah to master
    (this is the result of merging the most recent pull request
    prior to the currently open PR)
        
commit 46630ae...
Author: Me
Date:   Last week

    ...

If I run my script in a full (non-sparse) checkout of the repository, the result of git merge-base is 54adf... and the semantic significance of this that it is the state of the master branch after the most recent merge.

How do I get the same information (the "deviation point") when the checkout is sparse?

CodePudding user response:

The jenkins build may clone/fetch parts of the refs for lower time and storage cost. As it checks out a detached HEAD by git checkout -f <hash>, I guess it just fetches the PR only. It doesn't fetch master and/or master is not created in the local repository, and therefore master is unknown in the repository, like an undefined variable. To use an undefined variable raises errors.

In the script try git fetch origin refs/heads/master:refs/remotes/origin/master; git merge-base origin/master HEAD instead. It fetches master from the remote repository and stores it as refs/remote/origin/master or the short form origin/master.

If the job allows multiple builds concurrently, I suggest you replace origin/master with origin/master_somerandomwords in the commands for each build and remove it by git update-ref -d refs/remotes/origin/master_somerandomwords in the end, to avoid conflicts that multiple fetch processes try to update the same origin/master.

  •  Tags:  
  • git
  • Related