Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.lang.php > #16022 > unrolled thread

Pytanie o konfigurację GIT(lab)

Back to article view | Back to pl.comp.lang.php

Contents

  Pytanie o konfigurację GIT(lab) Marek S <precz@spamowi.com> - 2019-01-21 21:30 +0100
    Re: Pytanie o konfigurację GIT(lab) Borys Pogoreło <borys@pl.edu.leszno> - 2019-01-21 23:09 +0100
      Re: Pytanie o konfigurację GIT(lab) Marek S <precz@spamowi.com> - 2019-01-23 22:40 +0100
        Re: Pytanie o konfigurację GIT(lab) Borys Pogoreło <borys@pl.edu.leszno> - 2019-01-24 14:39 +0100
          Re: Pytanie o konfigurację GIT(lab) Marek S <precz@spamowi.com> - 2019-01-24 20:49 +0100
            Re: Pytanie o konfigurację GIT(lab) Borys Pogoreło <borys@pl.edu.leszno> - 2019-01-25 02:27 +0100
              Re: Pytanie o konfigurację GIT(lab) Marek S <precz@spamowi.com> - 2019-01-25 18:33 +0100
                Re: Pytanie o konfigurację GIT(lab) Marek S <precz@spamowi.com> - 2019-01-25 19:14 +0100
                  Re: Pytanie o konfigurację GIT(lab) Rafal Podsiadly <spinacz24@gmail.com> - 2019-02-11 21:42 -0800

#16022 — Pytanie o konfigurację GIT(lab)

Witam,

Mam dość nietypową sytuację. Otóż jest sobie pewien projekt PHP, który 
posiada pluginy. Pluginem jest katalog o nazwie tegoż pluginu (i to 
stanowi problem - dalej opiszę dlaczego) a w nim pliki i katalogi. 
Załóżmy, że są to katalogi PluginA, PluginB...

Autorami pluginów są różne osoby, którym przyświecały dwie koncepcje 
tworzenia repozytoriów. Pierwsza z nich to przechowywanie jedynie 
zawartości katalogu PluginA etc. Druga z nich to przechowywanie katalogu 
PluginA... i jego zawartości. Chciałbym to uporządkować. Byłoby idealnie 
gdyby dało się korzystać z GIT'a w środowisku PHPStorm.

Oto moje dylematy:

1. Rozwiązanie pierwsze.
Nie ma żadnego problemu by w lokalnym projekcie utworzyć ręcznie 
katalogi o nazwie pluginów a w nich synchronizować poszczególne 
repozytoria. Katalogi .git będą podrzędne do pluginu. Z PHPStorm działa 
to wyśmienicie. Ale... fraza klucz: trzeba ręcznie założyć katalogi o 
odpowiednich nazwach. Ja to wiem, ale inni mogą nie wiedzieć. Byłoby 
wygodniej (jest jeszcze inny powód, który pomijam) gdyby te katalogi 
tworzyły się same podczas git clone.

2. Jeśli wybierzemy rozwiązanie drugie i w poszczególnych repozytoriach 
umieścimy katalog PluginA, B, C... to nie da się przeprowadzić git clone 
gdyż nastąpi kolizja lokalizacji katalogu .git. Dla każdego pluginu 
powstanie on nad nim - a więc wszystkie w tym samym miejscu.

Macie pomysł co z tym zrobić?

-- 
Pozdrawiam,
Marek

[toc] | [next] | [standalone]

#16023

Dnia Mon, 21 Jan 2019 21:30:14 +0100, Marek S napisał(a):

> Macie pomysł co z tym zrobić?

Wrzuć to wszystko do Composera i niech on się martwi. Możesz zdefiniować
osobną regułę i źródłowe repo dla każdego z tych modułów i dla projektu
głównego. Będzie z tym jednak trochę pracy.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

[toc] | [prev] | [next] | [standalone]

#16024

W dniu 2019-01-21 o 23:09, Borys Pogoreło pisze:
> Dnia Mon, 21 Jan 2019 21:30:14 +0100, Marek S napisał(a):
> 
>> Macie pomysł co z tym zrobić?
> 
> Wrzuć to wszystko do Composera i niech on się martwi. Możesz zdefiniować
> osobną regułę i źródłowe repo dla każdego z tych modułów i dla projektu
> głównego. Będzie z tym jednak trochę pracy.
> 

Ale co dokładnie masz na myśli? Czy katalogi z pluginami będą wtedy 
trzymane w projekcie, czy obok niego + w projekcie symlinki do 
podkatalogów pluginów?

Zresztą chyba znalazłem odpowiedź znacznie prostszą. Otóż w GitLab jest 
tzw. slug name, który tworzy się automatycznie podczas nadawania tytułu 
projektu. Slug name jest przy git clone odpowiedzialny za nazwę katalogu 
w jakim powstanie lokalne repo + pliki. Odkryłem, że da się go zmienić 
na poziomie istniejącego projektu. Oczywiście rozwali to grupie 
możliwość korzystania z repo aż do momentu kiedy poprawią sobie lokalną 
konfigurację. Jest to również trochę pracy bo projektów jest sporo ale 
trzeba to jakoś uporządkować.

-- 
Pozdrawiam,
Marek

[toc] | [prev] | [next] | [standalone]

#16025

Dnia Wed, 23 Jan 2019 22:40:35 +0100, Marek S napisał(a):

> Ale co dokładnie masz na myśli? Czy katalogi z pluginami będą wtedy 
> trzymane w projekcie, czy obok niego + w projekcie symlinki do 
> podkatalogów pluginów?

W projekcie, w podkatalogu vendor.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

[toc] | [prev] | [next] | [standalone]

#16026

W dniu 2019-01-24 o 14:39, Borys Pogoreło pisze:
> W projekcie, w podkatalogu vendor.

Mam jeszcze pytanie natury konfiguracji Windows 10 aby było można łączyć 
się z GitLabem po SSH. Na makówce nie miałem z tym problemów. Jednakże 
dla W10 opis:

https://docs.gitlab.com/ee/ssh/

to jakiś szyfr. Każą zainstalować jakiś subsystem Linux. Nie da się pod 
Windows używać Git'a?

Wygenerowałem pod W10 bez instalowania czegokolwiek klucz prywatny i 
publiczny (marek i marek.pub).

  ssh-keygen -o -t rsa -b 4096 -C "mój email"

Publiczny przekopiowałem do Git'a. Prywatny jest póki co w przypadkowym 
miejscu. Gdzieś wyczytałem, że powinien on się znaleźć w 
Users/Ja/.ssh/id_rsa więc założyłem katalogi i go tam wrzuciłem. Nie 
działa.

Powtórzyłem operację pod Git Bash'em. Dorzucił mi plik known_hosts do 
.ssh plus nowe klucze w przypadkowym miejscu. Usunąłem je.

Połączenia z Git'em nie mam. Czy wiesz co jeszcze zrobić można? Może nie 
przewidziano, że użytkownicy Windows też chcieliby mieć repozytoria?

-- 
Pozdrawiam,
Marek

[toc] | [prev] | [next] | [standalone]

#16027

Dnia Thu, 24 Jan 2019 20:49:23 +0100, Marek S napisał(a):

> https://docs.gitlab.com/ee/ssh/
> 
> to jakiś szyfr. Każą zainstalować jakiś subsystem Linux. Nie da się pod 
> Windows używać Git'a?

Oczywiście, że się da. Zainstaluj po prostu normalną wersję:
https://gitforwindows.org/

Klucze SSH też normalnie działają. Może w W10 jest inaczej, ale w W8.1 nie
ma problemu.

-- 
Borys Pogoreło
borys(#)leszno,edu,pl

[toc] | [prev] | [next] | [standalone]

#16028

W dniu 2019-01-25 o 02:27, Borys Pogoreło pisze:

> Oczywiście, że się da. Zainstaluj po prostu normalną wersję:
> https://gitforwindows.org/

Dokładnie tego używam.

> Klucze SSH też normalnie działają. Może w W10 jest inaczej, ale w W8.1 nie
> ma problemu.

Wiesz... tylko nie bardzo sobie wyobrażam jak? No bo jeśli w 
przypadkowym miejscu i o przypadkowej nazwie wygenerują się klucze, to 
na chłopski rozum, należałoby poinformować GIT'a z jakiej lokalizacji ma 
brać te pliki i o jakich są nazwach.

Być może alternatywnie należy nadać im konkretne nazwy i w konkretnym 
miejscu umieścić. Nigdzie nie znalazłem żadnych informacji na ten temat. 
Tak jakby nikt SSH dla GIT'a nie używał pod Windowsem.

-- 
Pozdrawiam,
Marek

[toc] | [prev] | [next] | [standalone]

#16029

W dniu 2019-01-25 o 18:33, Marek S pisze:

No i znalazłem odpowiedź analizując jak rozlokowane są pliki na 
MacBooku, na którym pracuję. Odwzorowałem ją na PCcie, pozmieniałem 
nazwy i działa.

Popełniłem jeden błąd. Otóż polecenie:
ssh-keygen -o -t rsa -b 4096 -C "mój email"

zadziała poprawnie tylko wtedy, gdy na pytanie o nazwę plików klucza 
__nie_wprowadzi_się_niczego__. Tylko w tym przypadku powstanie katalog 
.ssh w użytkowniku z plikami o nazwach id_rsa oraz id_rsa.pub. GIT 
oczekuje istnienia pliku klucza prywatnego pod nazwą .ssh/id_rsa a nie 
dowolną nazwą. I to było przyczyną problemów.

-- 
Pozdrawiam,
Marek

[toc] | [prev] | [next] | [standalone]

#16042

W composer możesz zdefiniować katalog, w którym bedą przechowywane biblioteki. I nawet może to być katalog poza projektem. Do którego maja dostęp inne projekty. 
Co jest wysoce nie zalecane, gdyż aktualizacja vendora pociąga za sobą inne konsekwencje związane z weryfikacja wszystkich projektów.

Composer directory Source

[toc] | [prev] | [standalone]

Back to top | Article view | pl.comp.lang.php

csiph-web