Zilele trecute vorbeam cu @andySF despre o limitare a Git. Problema lui: în Git nu sunt ținute anumite informații despre fișiere, cum ar fi data la care respectivul fișier a fost creat (deci nu data la care a fost adăugat în repo ci când a apărut fișierul pe disc)
Eu am zis că nu e treaba Git să țină cont de aceste detalii. El a zis că nu i se pare normal să piardă informație.
Cine are dreptate? De ce?
Si eu as tinde sa spun ca nu e treaba Git, dar in ce scenariu ai avea nevoie de informatia respectiva stocata pe Git ?
In primul rand, nu e de inceredere. Daca nu ma inseala memoria, pana la Win7(inclusiv) daca faceai move de pe o partitie pe alta, se facea prin copy + delete si aveai alt timestamp
Data la care fisierul a fost creat e data cand a fost introdus in git, daca ceva nu e in git nu exista.
Pai “creation time” nici macar nu e ceva standard, daca ne uitam un documentatia lui stat(), avem structura asta:
struct stat {
dev_t st_dev; /* ID of device containing file */
ino_t st_ino; /* inode number */
mode_t st_mode; /* protection */
nlink_t st_nlink; /* number of hard links */
uid_t st_uid; /* user ID of owner */
gid_t st_gid; /* group ID of owner */
dev_t st_rdev; /* device ID (if special file) */
off_t st_size; /* total size, in bytes */
blksize_t st_blksize; /* blocksize for file system I/O */
blkcnt_t st_blocks; /* number of 512B blocks allocated */
time_t st_atime; /* time of last access */
time_t st_mtime; /* time of last modification */
time_t st_ctime; /* time of last status change */
};
Si eu as tinde sa spun ca nu e treaba Git, dar in ce scenariu ai avea nevoie de informatia respectiva stocata pe Git ?
Am avut nevoie să actualizez informațiile de copyright din headerul fiecărui fișier după un template care include și data la care a fost creat fișierul.
In primul rand, nu e de inceredere. Daca nu ma inseala memoria, pana la Win7(inclusiv) daca faceai move de pe o partitie pe alta, se facea prin copy + delete si aveai alt timestamp
Asta nu înseamnă că nu e o limitare.
Data la care fisierul a fost creat e data cand a fost introdus in git, daca ceva nu e in git nu exista.
Este un proiect foarte vechi pe când nu foloseam vcs iar primul vcs a fost svn.
Pai “creation time” nici macar nu e ceva standard, daca ne uitam un documentatia lui stat(), avem structura asta:
Într-adevăr sunt sisteme de fișiere care nu suportă creation date sau a fost oprit din motive de performanță sau modelul de permisiuni e diferit dar ăsta nu e un motiv suficient de bun să pierzi informații. Dacă ele există, păstrează-le.
Indiferent ce scuze veți găsi, nu ar trebui să pierzi informație. Pentru mine vcs a fost direct responsabil din moment ce el este responsabil de crearea fișierelor. E ca și cum ai trimite lucruri prin poștă într-un recipient și ar ajunge la destinație în alt recipient.
Ai o cerere foarte specifica. Se rezolva cu hooks si un script pentru citirea/setarea metadatelor. Metadatele tin de sistemul de fisiere, daca le vrei in git le citesti si le setezi in functie de cum ai nevoie.
.git/hooks/git-store-meta.pl --store -f user,group,mode,mtime,atime
si
.git/hooks/git-store-meta.pl --apply
Practic tu propui ca un sistem de control sa importe o informatie pe care n-o poate controla si care informaţie e disponibilă doar prin hack-uri (de exemplu citind direct filesystem-ul), deoarece stat() nu furnizeaza informatia aia. Oricat de “corect” ar parea, ma indoiesc ca se va intampla.
Mulțumesc. Am să studiez.
A fost o chestie de care nu știam că voi avea vreodată nevoie și probabil nu voi mai avea nevoie în viitor vreodată dar discutam pur teoretic dacă e ok sau nu să pierzi informație.
Version control is not backup (ad-literam). Înțeleg de ce a avut @andySF nevoie de informațiile repective dar nu mi se pare că pică în sarcina sistemelor de versionare.
Sunt aplicații pentru backup / snapshots care păstrează toate informațiile despre fișierele tale, dar nu folosim așa ceva să ne versionăm codul, nu? Pentru că sunt greoaie.
În plus, dacă ar stoca atâtea detalii, sistemele de versionare ar consuma mai multe resurse. Câțiva bytes la un fișier nu e mare lucru, dar într-un proiect mai măricel dezvoltat pe o perioadă mai lungă tinde să se adune. Și dacă mai luăm și cazul DVCS, toată lumea ar plimba informațile astea de colo colo.
PS: să nu uităm de problemele generale legate de timp: setările de fus orar și conversia la UTC, care nu are tot timpul rezultatele așteptate.
@redecs
De fapt s-ar putea crea un git cu snapshot-uri cu ZFS/btrfs (chiar ar fi mult mai rapid si aproape nu ar ocupa spatiu deloc), doar ca nu foloseste mai nimeni ZFS pe un desktop.
Da, la ZFS mă gândeam și eu când am zis snapshots, dar nu știu pe nimeni care să folosească ZFS pe desktop (deschizi Chrome și nu îți mai rămane RAM și pt ZFS 
)
Aici e vorba de un timestamp, ca si pentru ceilalti “timpi” stocati de source control, asa ca nu ar fi asta o problema IMO.