Gitlab diff between Merge Request Target branch and Source Branch in pipeline

My use involves finding a diff between Merge Request and Master or Release branch (whichever branch I want to diff against) the MR will have CI_MERGE_REQUEST_TARGET_BRANCH set.

CHANGED_DIRS=$(git diff --name-only ${CI_MERGE_REQUEST_TARGET_BRANCH_NAME}...${CI_COMMIT_REF_NAME} | xargs -L1 dirname | uniq | cut -d'/' -f1 |tail -n+2 | uniq)

But it seems that gitlab doesn't recognize the Merge request target branch diff and gives this output.

fatal: ambiguous argument 'master...source': unknown revision or path not in the working tree.

How do I find the diff (which are directories). Appreciate help !

This is not really a Git issue, but rather a GitLab-CI issue. However, these particular issues crop up in multiple CI/CD systems, always with the same general reason:

• Making a full clone of a large repository is slow.
• CI systems often start by cloning a repository.
• Hence, CI systems often start by making a less-than-full clone of the repository.
• Git offered just two ways to do this in the past:¹ shallow clones and single-branch clones. In fact, they tend to go together: making a shallow clone, with git clone --depth number, also makes a single-branch clone unless you forcibly override Git's default by adding --no-single-branch as well.

Now, the clone command in any given CI/CD system may be controllable, or may be done by the CI/CD system before any software knobs that are available to you-as-a-developer are provided. If you can affect the command, that's usually the way to go, but if not, you may still be able to correct the problem by running additional Git commands (this again depends on the CI/CD system):

• git remote set-branches --add allows you to add various branches to an otherwise single-branch clone;
• git fetch --depth number, git fetch --deepen number, and git fetch --unshallow are three ways to alter the depth of an existing shallow clone, or remove the depth restrictions entirely.

If your CI/CD system makes a shallow, single-branch clone, and you need a deeper clone with more remote-tracking names, you can get that using git remote and/or git fetch.

As I haven't used GitLab's CI system, I cannot provide a recipe here, but based on comments, it sounds like they use --depth 50 by default. If you have a depth knob, setting it to zero (0) is the usual way to disable the --depth argument, which also disables the single-branch-ness.

Do note that regardless of how the system clones your repository, you will generally have only one branch name, or perhaps even none (detached HEAD) when cloning via tag. A full clone will have a full set of remote-tracking names, while a single-branch clone will have only one remote-tracking name until you use git remote to adjust this and run a subsequent git fetch to add more remote-tracking names.

With GitHub Actions, the v2 checkout makes a shallow single-branch clone by default, while the v1 checkout makes a full clone.

¹There is now a third method, the so-called partial clone with promisor remotes. This is arguably the right way for a CI system to do the trick, but partial clones are not very good yet, for a lot of reasons, so this probably has to wait for improvements to the implementation.