Springe zum Hauptinhalt Profilbild Hartmut Goebel

Hartmut Goebel

Diplom-Informatiker, CISSP, CSSLP, ISO 27001 Lead Implementer

Anfrage
☰
Logo Goebel Consult

In need for an enhanced git URL scheme

Which allows specifying heads/branches and paths within the repository.

Which allows specifying heads/branches and paths within the repository.

I'm currently testing project-builder, to tool for easily building software for different Linux distributions. One of the features of this tool is to check out the configuration from a source code management system. Well, with git this becomes quite a problem, as one can not specify the branch nor a path within the repo when cloning.

So I'm proposing an extended git URL schema:

Example:

git://<host>/path/to/git/repo?h=devel&p=src/Makefile

Which means:

  • The repository itself is passed as URL as usual

  • The head (aka branch) is passed as query parameter "h"

  • The file or directory is passed as query parameter "p"

Reasoning

For cloning the repository, git needs to know the repository URL. When passing a URL like cgit uses, git can not decide which part of the path belongs to the repo and which part is below. Git would need to walk the URL-path up until it is able to find access a valid repository. This behaviour is not desired as it may have unexpected side-effects, esp. when accessing a a http-based repository.

This means: The part-part of the URL must only contain the path to the repository!

So obviously there is a need for specifying the head/branch to access. This is given as a query parameter. I decided to use "h" like "head" like cgit does.

If one wants to specify a certain file or directory within the repository, this is as a query parameter, too. I decided to use "p" like "path".

FAQ

Why not using the notation /BRANCH/path?

See above: When cloning, git would need to walk the URL-path up until it is able to access a valid repository. This behaviour is not desired as it may have unexpected side-effects, esp. when accessing a a http-based repository. Additionally git does not support this when cloning local repositories. (Try something like git clone /path/to/repo/master/Makefile.) So this would implement an asymmetry.

Why not using the notation /path@BRANCH?

This would inhibit using an @-sign in any path. Plus it does not solve the problem described in the /BRANCH/path-case.

Why not using the notation /tree/BRANCH/path?

Same problem here: git could decide which part of the path belongs to the repo.