@yuio: ciekawy czy rozumie rebase vs merge w takim razie..

@wsciekly_pstrong gównoburza o coś takiego? XD

@wsciekly_pstrong

no rozumiem, że wg ciebie jest to ok.

Nie jest ok, ale nie jest powodem do gównoburzy, a jedynie skwitowanie tego śmieszkiem, zrobienie poprawki i przejście dalej nad tym do porządku dziennego

ale nie chciałbym pracować z Tobą

Ja też z Tobą nie, bo masz kija w d.... oraz robisz gównoburzę z błahych powodów.

@look997 taaa a potem będzie push force do mastera ( ͡° ͜ʖ ͡°)

@NoMoreTearsJustSmile: znając życie to pewnie wszelkie propozycje będą pchać do mastera, nikt się nie będzie przejmował tym by zaciągnąć aktualną wersję i ogólnie będzie taki chaos, że i tak to wszystko wydrukują i ręcznie przepiszą to co myślą że jest ostateczną wersją.

@ProbablyHappy: to z tego co napisałeś to pewnie brakuje Ci zmiany brancha z defauktowego "main" na którym jest tylko gitignore i readme na jakiś inny branch na którym są interesujące Cię pliki. Żeby zmienić brancha napisz git checkout nazwabrancha.
A jak chcesz to wypchnąć na swoje remote, pamiętaj o zmianie remote (git remote set URL czy coś w tym stylu) na swoje

@Kryspin013: visudo do tego raczej nie służy.

@fjiwoejflksadfweirunxwiurenyf: to nie ma znaczenia, spełnia dokłądnie tą rolę. To jest oskryptowany vim, który pracuje na plikach tymczasowych a jego zamysłem było dobezpieczenie edycji plików przez sudo.

@wytrzzeszcz: vim plikdozapisania -s plik_wejściowy
Po czym plik wejściowy kasujesz. Plik do zapisania będzie zapisany jak zapiszesz, nie stworzy się o ile nie zapiszesz.

@jan-kowalski668: tak, też pomyślałem o origin/master, tylko że jak zrobisz fetch to już masz tam najnowsze zmiany. A czasem chcę porównać z tym co było zanim ją zacząłem. Ciężko wytłumaczyć, więc przykład: Robię sobie coś, ale jest jakiś błąd. Nie wiem czy to moja zmiana go spowodowała czy już tak było. Przełączam się na mastera i widzę czy był ten błąd. Mógłbym się przełączyć na origin/master, ale jak zrobiłem fetch (żebyPokaż całość

@Spofity: Myślę że 6-7k

@Spofity: 3-2,5k

@becvvv: Też nie rozumiem, przecież jak jest konflikt to pojawia się ikonka i nie można mergować. I to wystawiający MRa powinien ogarnąć, bo bez tego nie ma sensu robić review.

Czy zamiast tego da się zrobić tak, by to pracownik A rozwiązywał konflikty, a pracownik B tylko akceptował mr? W gitlabie nie widzę takiej opcji.

@becvvv: nie rozumiem. Jest konflikt to twórca go rozwiązuje. Tak to działa chyba wszędzie

@s_theCapt: git log --reverse --since=3.week.ago --stat --oneline i podobne. Jak chcesz to porozbijać, to for i in $(seq 1 31); do to co wyzej since=$i.days.ago ... może niezupełnie to co chcesz, ale przy odrobinie wysiłku, wycinania przy pomocy head i tail da rade. Oczywiście możesz też sięgnąć po pythonowy moduł git i inne podobne rozwiązania

@jan-kowalski668: mozesz do ich wspolnego brancha (master albo staging albo cokolwiek) dodac commit z plikiem i zrobic rebase tych 3 branchy na ten commit z nowym plikiem

jak nie masz takiej mozliwosci i bedzie duzy problem, to dodaj commit z plikiem do jednego z tych branchow i potem cherry-pick tego commita na inne branche, ale nie wiem czy powinienes robic kolejne branche, tylko pracowac na tych trzech?

A->A1, B->B1, C->C1

@jan-kowalski668: whatever, odpowiedz na pytanie "czy powinienem stworzyć brancha" brzmi zawsze nie, bo to zależy od twoich preferencji

każdym utworzonym branchu zrobić cherry-pick commita z plikiem

@jan-kowalski668: jeśli branche nie są takie same to nie zrobisz tego inaczej niż cherry-pic. Ewentualnie rebase, ale to przecież to samo

Generalnie odpowiedz brzmi: tak

gihub to chyba niechętnie na to patrzy jak się trzyma prywatne dane tam

@decentralizacja: "chyba" xd o co ci dokladnie chodzi?

@decentralizacja: To 500 MB jest na pakiety, a nie na pliki w gicie. Raczej nie mają problemu z prywatnymi repo skoro od czasu przejęcia przez Microsoft znieśli na nie limit dla bezpłatnych kont.

A poszedł wcześniej git push --force?

@Pietr: a chcesz ten plik w historii czy nie? Możesz łatwo usunąć duże pliki przy użyciu git filter-repo --strip-blobs-bigger-than 10M tyle, że to nadpisanie historii i całe repo będzie miało inne hashe

@Pietr: widzę też, że jest tool do migracji do lfs https://notiz.dev/blog/migrate-git-repo-to-git-lfs

@przemyslaw-maczka: czasem jest śmiesznie, jak się okazuje że team X pracował pół roku na branchu nad rozwojem ficzera, który team Y usunął z aplikacji 3 miesiące temu na wniosek stakeholderów, a product ownerzy i management jakoś się nie dogadali na tych swoich magicznych meetingach i nikt nie ogarnął

@przemyslaw-maczka: jak się często nie rebasuje to tak się kończy ( ͡° ͜ʖ ͡°)

@julia__hk: a co z tymi co mają ownera chociaż w jednej organizacji?

@masiakla: to juz level king of my castle ( ͡° ͜ʖ ͡°)

@passage: i wtedy #!$%@? cię strzela, bo koledzy nie ogarniają gita i nie potrafią utrzymać prostej historii commitów

@passage: mam to w sumie zaliasowane pog gitlog, ale i tak akurat do podglądu drzewa to mam plugin w vscode albo na gitlabie sobie patrzę