ugrás a tartalomhoz

git vs dátumok

mind1 valami név · 2020. Szep. 14. (H), 10.06
Az normális, hogy a git nem tartja meg az általa kezelt fájlok eredeti dátumait pl. egy branch váltáskor?
Pár napja tűnt fel, hogy a checkout után minden érintett fájl dátuma átíródott a checkout időpontjára, ami bizonyos esetekben eléggé zavaró számomra.
git - béta/testing élesítés ›
 ■
1

Build eszközök miatt van így,

Endyl · 2020. Szep. 14. (H), 10.21
Build eszközök miatt van így, hogy észrevegyék, hogy változott a fájl:
https://git.wiki.kernel.org/index.php/GitFaq#Why_isn.27t_Git_preserving_modification_time_on_files.3F

De a gitben benne van az infó, szóval ha nagyon zavar, írhatsz rá valami eszközt, ami beállítja a neked tetsző dátumot.
2

Na épp ez jutott eszembe: egy

mind1 valami név · 2020. Szep. 14. (H), 10.34
Na épp ez jutott eszembe: egy sima make. Ha nem szkriptnyelvekkel dolgoznék, hanem fordítani kellene valamit, így a make azonnal rebuildelné a teljes kódot, ha valamelyik fájl változott a branch-ek közt, holott valószínűleg szükségtelen lenne, hiszen akar hónapok, évek óta is érintetlen lehet az a fájl.

Közben megnéztem a linked, kutya legyek, ha értem a logikáját.
3

Elvileg csak azoknak a

Endyl · 2020. Szep. 14. (H), 10.58
Elvileg csak azoknak a fájloknak kellene frissítenie a módosítási dátumát, amik különböznek a két branch/commit között, nem mindegyiknek.
4

Az bőven elég adott

mind1 valami név · 2020. Szep. 14. (H), 11.38
Az bőven elég adott esetben.
Valami olyan lib forrása, ami sok kódot érint...
Szerintem, mivel a branch váltásakor az összes fájl lecserélődik, ami eltér, egyedül a commit-ból kimaradt (új?) fájlok maradnak meg a váltások közt, elvileg nem lenne szabad konfliktust generálnia a checkout-nak.
Szerintem.
De lehet, hogy csak én nem látom át.
5

Ez még gázosabb, mint

mind1 valami név · 2020. Szep. 15. (K), 07.05
Ez még gázosabb, mint gondoltam. Ha manuálisan használom a git-et (nem IDE alól, automatizálva), akkor a branch váltásokkal agyon is vághatom a kódomat, ha figyelmetlen vagyok.

Módosítok valamit, majd commit nélkül checkout, újabb módosítás, commit és a másik branch-hez tartozó forrás máris az aktuálisban landol...

Akartam készíteni egy demot, hogy miért érzem problémásnak a linkeden lévő indoklást és pont ezt sikerült elkövetnem, viszont rollbacket nem tudom, lehet-e egyszerűen... Szóval majd rendes gépről csinálom újra, ahol nem arra kell figyelni, hogy valóban azt írtam-e, akit akartam. (Mobil "billentyűzet" gyönyörei :( )


stackoverfliw - de legalább megnyugodtam, hogy nem vagyok ennyire feledékeny, csak megváltozott valami a git működésében, mióta utoljára használtam a branch-eket.
6

Nem tudom, én alapból erre a

Endyl · 2020. Szep. 15. (K), 11.36
Nem tudom, én alapból erre a működésre a számítottam. És mi változott? Mert én amióta használom, úgy emlékszem, hogy a git így működött, és semmiféle figyelmeztetésre sem emlékszem, hogy valami változni fog.
7

Nekem olyan emlékem volt, és

mind1 valami név · 2020. Szep. 15. (K), 11.43
Nekem olyan emlékem volt, és ezt ott a linken ha jól értem, megerősítették, hogy változtatás után nem engedett checkoutot, míg nem adok ki commitot vagy tüntetem el a modosításokat.
És kb ezt is várnám tőle, mert jelen állapotában nagyon könnyű agyonvágni a különböző verziókat.
8

Akkor nem enged checkoutot,

Endyl · 2020. Szep. 15. (K), 11.53
Akkor nem enged checkoutot, ha a változtatások konfliktusban vannak az új branch fájljaival. Például ha van egy új fájlod, ami nem része egyik branchnek sem, akkor ahhoz nem nyúl, és simán lehet váltani.

Mondjuk én mostanra már rászoktam a rendszeres git status-olásra, ha nem vagyok 100%-ig biztos, hogy mi a helyzet. Mint az ls használata parancssoros könyvtárnavigáció esetén.
9

Hát valamit vagy elcsesztem,

mind1 valami név · 2020. Szep. 15. (K), 12.47
Hát valamit vagy elcsesztem, vagy a termux-ban, mobilon futó get kicsit hülyébb, mint a desktop verzió.
Ott ugyanis szó nélkül átrakta a módosított, de nem kommitált fájlt a másik branchbe.
Sajnos log nem készült, nem tudom reprodukálni, mit csináltam.
Laptopon valóban úgy működik, ahogy vártam.
10

Akkor sem panaszkodik a git,

Endyl · 2020. Szep. 15. (K), 12.52
Akkor sem panaszkodik a git, ha egy olyan fájlt módosítottál, aminek a legutóbb commitolt tartalma megegyezik a két branchen. Esetleg ebbe futottál bele?
11

Nem. Csináltam egy main.c és

mind1 valami név · 2020. Szep. 15. (K), 13.11
Nem. Csináltam egy main.c és egy teszt.h fájlt, utóbbit include-olta az előbbi. A teszt.h tartalmazott egy helloworld stringet, csak az egyikben 00 a másikban 01 sorszámmal.
És ezt sikerült valahogy úgy megoldani, hogy a master és a br0 branch közt szabadon hurcoltam és ahol kiadtam a commit-ot, ott hagyta.
Legalábbis így emlékszem, de így utólag bármi lehetett.
Mindegy, a lényeg, hogy most és itt azt csinálja, amit elvártam tőle.
Kivéve a dátumokat, mert ugye azok miatt rendszeresen újrafordít mindent. :)

Valami halovány dolog azért kezd derengeni: a binárist nem szokás commitolni, jó helye van annak a .gitignore-ban. Emiatt van benne ráció, hogy branch váltáskor inkább gyártson újat belőle.
13

Hurcolhatod is

Pepita · 2020. Szep. 15. (K), 13.17
a master és a br0 branch közt szabadon hurcoltam és ahol kiadtam a commit-ot, ott hagyta
Pont ez a lényeg, hogy amit változtatsz, az akkor kerül be az aktuális branch-be, amikor azt mondod, hogy commit.
Enged branch-et váltani, ha ez nem "bántja" a pillanatnyi (még nem commitált) munkádat, berinyál, ha conflictol.
Ekkor még van lehetőség a stash -sel játszani, ha fontos gyorsan valamit megcsinálni a másik branch-en, utána vissza lehet (stash pop) hozni a változtatásaidat.
Viszont vigyázni kell, mikor melyik branch-en vagy... :)
12

+1

Pepita · 2020. Szep. 15. (K), 13.11
már rászoktam a rendszeres git status-olásra
Hasonló okokból én is. :)
Checkoutolni egy-egy fájlt is lehet, ekkor figyelmeztetés nélkül buknak a nem commitolt változások.
"konfliktusban vannak" alatt ugye mindketten azt értjük, hogy az adott fájl mindkét branch-ben változott, és nagyjából ugyanott?
Vagyis akkor "rinyál", ha a jelenlegi brach is masterből származik és az új is, de nálam is és azon is változott a test.txt 3. sora.
14

Nem hiszem, hogy van

Endyl · 2020. Szep. 15. (K), 13.40
Nem hiszem, hogy van jelentősége a nagyjából ugyanottnak. Egyik commitról másikra váltásnál ha a fájlok tartalma nem egyezik meg a két commitban és van nem mentett változás, akkor nem lesz váltás. Részletesen és szélsőséges esetekkel le van írva a dolog a fentebbi SO linken.

Illetve ha már itt tartunk, akkor a feledékenységből fakadó hibák kivédésére szintén hasznos a git add -p.