GIT API - czy można prorównać plik w dwóch różnych repozytoriach?

Cześć, napisałem program który za pomocą zapytań REST porównuje commity w dwóch remote repozytoriach (z gitlaba do bitbucketa) i jeśli się różnią to przepycha je z jednego repo do drugiego tak aby w obu ostatni commit był taki sam. Chciałbym to rozbudować o sprawdzenie czy w commitach które mają zostać przepchnięte zmieniony został konkretny plik. Chodzi o to że przy okazji merge do mojej gałęzi developerzy czasami nadpisują mi pliki konfiguracyjne więc chcę zrobić powiadomienie które przed przepchnięciem zaległych commitów wymusi decyzję T/N jeśli jakiś konkretny plik też jest zmieniany.

Jakiś pomysł jak to ugryźć?

A git ignor na tym pliku nie wystarczy?

@UglyMan: no właśnie coś nie działa... Ogólnie to wygląda tak że mam 2 remote'y i repozytorium lokane. Ściągam z jednego remota do repozytorium lokalnego i wypycham do drugiego remota. W obu mam gitignora i niestety nie działa.

Git ignor działa, tylko wpisujesz złe ścieżki plikow. Nie ma innej opcji.

Jeżeli developerzy nadpisują ci konfiguracje przy okazji mergowania to masz problem z workflow.
Podczas merge request ty rozwiązujesz konflikty.
Możliwość zatwierdzania merge requestow powinna być ograniczona, a osoba odpowiedzialna powinna dokonywać DoD mergowania, której składową będzie sprawdzenie konfiguracji.

@DKN: Ktoś mi powiedział że git ignor powinien być tylko w jednym miejscu i wtedy to zadziała. Zastanawiam się w którym:

1. W remote z którego kody są pobierane
2. W lokalnym repo do którego kody są pobierane
3. W remote do którego kody są wypychane
   ps. git ignor nie rozwiązuje sprawy bo czasami te pliki są słusznie nadpisywane
   ps.2 te ścieżki trzeba podawać w jakiś specjalny sposób że obie to źle?

MR rozwiązują programiści i to jest dobre podejście. Szukam rozwiązania w którym podczas przepychania kodów między GitLab'em a Bitbucket'em wychwycę nadpisywanie konfiguracji, w tym momencie wstrzymam wszystko i sprawdzę czy nadpisanie konfiguracji jest poprawne czy nie. Nie chcę sprawdzać commita po commitcie żeby znaleźć czy takie nadpisywanie plików kofiguracyjnych miało miejsce bo rzadko kiedy ma. Chce wyrzucić sobie powiadomienie o tym że coś takiego ma miejsce i a wtedy sprawdzę czy jest poprawne.

aksimoN napisał(a):

Szukam rozwiązania w którym podczas przepychania kodów między GitLab'em a Bitbucket'em wychwycę nadpisywanie konfiguracji, w tym momencie wstrzymam wszystko i sprawdzę czy nadpisanie konfiguracji jest poprawne czy nie..

Jeśli flow z gitignore Ci nie działa i developerzy nadpisują Ci pliki to dodaj sobie joba do tego pipelina co robi Ci sync pomiędzy gitlabem a bitbucketem, który będzie sprawdzał po prostu, czy dane pliki się zmieniły. I w zależności od jego wyniku albo automatycznie przepycha dalej, albo wysyła powiadomienie i czeka z resztą synchronizacji na twoją akcję.

Jest możliwe nadal zacommitowanie pliku który jest w .gitignore, to że plik jest w .gitignore nie znaczy że nie będzie nigdy zacommitowany, tylko że nie będzie dodawany do "staged area" domyślnie. Ale zacommitować go można.

Co prawda, trzeba by specjalnie chcieć zacommitować taki plik, żeby Ci zrobić na złość. Bo faktycznie, jeśli plik jest w .gitignore, to przypadkiem się go raczej nie zacommituje.

aksimoN napisał(a):

Cześć, napisałem program który za pomocą zapytań REST porównuje commity w dwóch remote repozytoriach (z gitlaba do bitbucketa) i jeśli się różnią to przepycha je z jednego repo do drugiego tak aby w obu ostatni commit był taki sam. Chciałbym to rozbudować o sprawdzenie czy w commitach które mają zostać przepchnięte zmieniony został konkretny plik. Chodzi o to że przy okazji merge do mojej gałęzi developerzy czasami nadpisują mi pliki konfiguracyjne więc chcę zrobić powiadomienie które przed przepchnięciem zaległych commitów wymusi decyzję T/N jeśli jakiś konkretny plik też jest zmieniany.

Ja bym się przede wszystkim zapytał tak:

• Robisz tylko wypchnięcie z jednego remote'a na drugi, czy robisz dodatkowo jakieś rzeczy? merge/rebase/cherry-pick/reset coś innego?
• Robisz commity po swojej stronie (git add, git commit, coś innego)? Czy tylko przerzucasz gotowe commity między remote'ami?

To czemu ja bym się przyjrzał na pewno, to to, czy te repozytoria po działaniu Twojego skryptu się nie rozjadą. Bo jeśli np za miesiąc miałoby być tak że na jednym repo jest 1000 commitów więcej niż na innym, to nie wróżę dobrze.

Może po prostu opisz nam dokładnie jak Twoje rozwiązanie działa, i wtedy Ci powiemy czy gdzieś jest luka?

PS: Aha, noi upewnij się że .gitignore na obu remote'ach oraz na Twoim lokalu są takie same.

A czemu nie użyjesz zwyczajnie 2 remote i przepchniesz tak? Bo zakładam, że to co robisz to ma być zwyczajny mirroring.