Gitlab refs compatibility

[juanmcasanova]

When using GitLab CI, a couple of custom refs are created in the GIT repository by GitLab to prevent errors with force-pushes and such (as far as I know "refs/pipelines/" and "refs/merge-requests/").

The problem is that this library checks every ref type in the repository and throws a RuntimeException if it doesn't recognize one:

gitlib/src/Gitonomy/Git/ReferenceBag.php

Lines 352 to 376 in b4620be

	foreach ($parser->references as $row) {
	list($commitHash, $fullname) = $row;
	if (preg_match('#^refs/(heads|remotes)/(.*)$#', $fullname)) {
	if (preg_match('#.*HEAD$#', $fullname)) {
	continue;
	}
	$reference = new Branch($this->repository, $fullname, $commitHash);
	$this->references[$fullname] = $reference;
	$this->branches[] = $reference;
	} elseif (preg_match('#^refs/tags/(.*)$#', $fullname)) {
	$reference = new Tag($this->repository, $fullname, $commitHash);
	$this->references[$fullname] = $reference;
	$this->tags[] = $reference;
	} elseif ($fullname === 'refs/stash') {
	$reference = new Stash($this->repository, $fullname, $commitHash);
	$this->references[$fullname] = $reference;
	} elseif (preg_match('#^refs/pull/(.*)$#', $fullname)) {
	// Do nothing here
	} elseif ($fullname === 'refs/notes/gtm-data') {
	// Do nothing here
	} else {
	throw new RuntimeException(sprintf('Unable to parse "%s"', $fullname));
	}
	}

I can make a pull request to fix this, but wouldn't it be better to ignore any unknown reference instead of having to manually include each of them in this file?

[alexandresalome]

I think it's a good idea.

[GrahamCampbell]

NB GitHub also has refs of the format refs/pull/{pr}/head where {pr} is an integer PR number.

[GrahamCampbell]

I was going to say that skipping unknown stuff would be a bad idea, because it would make the count() function confusing, but we already skip stuff, looking at the code. Maybe skipping everything unknown is going to be the best approach.

[alexandresalome]

And for backward compatibility, that would be better.

Maybe we could start a list of "things to do for next major version".

[juanmcasanova]

I agree it is better to do it in a major version, as it could break things for some people if they expect gitlib to ignore those references.