Git-repository-URL – SSH-syntaxis zonder absoluut pad

Ik gebruik een git-repositoryserver die toegankelijk is via SSH, op een aangepaste poort (laten we zeggen 12345). Ik heb ontdekt dat in dit geval de repository-URL’s moeten worden opgegeven met behulp van de SSH-syntaxis:

git clone ssh://[email protected]:12345/absolute/path/to/repository

Ik zou het zo willen instellen dat gebruikers repositories kunnen klonen zonder het absolutepad op te geven.

git clone ssh://[email protected]:12345/repository.git

Ik heb het onderwerp onderzocht en de volgende opties gevonden:

1. Verwijder de aangepaste poort uit de URL en laat de gebruikers deze toevoegen aan hun ~/.ssh/config-bestand (een tijdelijke oplossing in plaats van een oplossing).
2. Laat SSH vallen en gebruik git-daemonen specificeer de parameter --base-path(nog steeds een tijdelijke oplossing…)
3. Gebruik een hulpprogramma zoals gitosisof gitolite– maar zou het niet overdreven zijn om het alleen voor dit doel te gebruiken? Gitosis wordt stopgezet, gitolite is een behoorlijk groot stuk software…

Alles wat ik wil is een “mooiere” SSH-URL met aangepaste poort (zodat ik het hele git clone-commando kan distribueren en niets meer van de externe gebruiker nodig heb). Welke van de bovenstaande oplossingen zou in mijn geval het meest haalbaar zijn?

Antwoord 1, autoriteit 100%

Als je de alternatieve vorm van sshURL’s gebruikt, heb je geen absoluut pad nodig. Bijvoorbeeld…

git clone [email protected]:repos/myrepo.git

…zal repository repos/myrepo.gitklonen ten opzichte van mijn homedirectory, hoewel dit het gebruik van een alternatieve poort niet toestaat. U kunt echter ook ~in beide vormen gebruiken om de homedirectory van de gebruiker aan te geven, bijvoorbeeld:

git clone ssh://[email protected]:12345/~/repository.git

Overigens werkt gitosisondanks de stopzetting redelijk goed, en de code is zowel klein als gemakkelijk te begrijpen. Het biedt een handige set toegangscontroles en zelfbedieningsbeheer van repositories. Ik zou het niet helemaal afdoen.

Antwoord 2, autoriteit 9%

Ik doe dit, niet precies wat je vroeg, maar dichtbij en met mooiere links:

maak een pad zoals

/srv/git 

waar je je git-projecten plaatst

maak vervolgens een symbolische link naar huis:

ln -s /srv/git $HOME

vervolgens kunt u kortere links hebben

git clone user@server:git/myproject.git

Als je een enkel project hebt, kun je de git/part in de url verwijderen

ln -s /srv/git/myproject.git $HOME

volgende

git clone user@server:myproject.git

zal werken.
Natuurlijk komt de .git aan het einde van de URL alleen van het maken van de kale met .git in de naam.
Merk ook op dat het ssh://-gedeelte niet nodig is: de @ impliceert dat het een ssh-URL voor git is.

Bijgewerkt: laat me een kanttekening maken: volgens de meest recente Bestandssysteemhiërarchiestandaarddie ik gebruik nu /srv/gitals repository-locatie.

Antwoord 3

Ik weet niet zeker of dit echt een heel antwoord verdient, maar ik ben het beu om te vechten met commentaarspecifieke opmaakregels. Ik kom zeggen:

Ik wil er alleen aan toevoegen dat dit een versiespecifieke wijziging lijkt te zijn, hoewel ik niet zeker weet of het aan de clientzijde of aan de server/repo-houder is: ik heb een .git/configbestand met veel URL’s zoals:

[remote "bob"]
    url = ssh://ME@MACHINE<strong>/~ME</strong>/repositories/REPO.git
    fetch = +refs/heads/*:refs/remotes/bob/* 

Ze werkten allemaal toen ik ze instelde… in 2010, en werkten nog steeds de laatste keer dat ik die afstandsbedieningen gebruikte, in 2016 of zo.

Nu, op versie 2.18.0, werken die niet, en ik moet de notatie :/~ME/fooof :/~/foogebruiken . Dat wil zeggen dat wat je probeert te doen niet altijd verkeerd is geweest.