Det kommer an på. 😃 GitHub setter en grense, og den har jeg støtt på iblant.

Snakker vi in binaries da, eller? :thinking_face:

Jeg liker å holde store binaries utenfor ved å bruke https://git-lfs.com eller lignende.

> Snakker vi in binaries da, eller? :thinking_face: > I mitt tilfelle: • Bilder • Tredjeparts Javascript (i et prosjekt der jeg ikke ønsker å ha NPM eller et byggesteg)

Tidligere har jeg angret etter å ha sjekket inn store filer. • Selve git-repoet blir stort, kloning tar lang tid • Fordi Git-repoet er stort, tar byggesteget lenger tid • I ett særtilfelle krasjet bygget fordi repoet var for stort. Da hadde jeg sjekket inn store PDF-er som til sammen var mmate hundre megabyte. Samtidig liker jeg at alle filene man trenger å vite om er i Git-repoet.

Jeg må lese litt mer om Git LFS - ser ut som jeg ikke visste helt hva det var alikevel. Takk!

Vi støtte også nylig på grensa til Github 😅

Ikke noe jeg vanligvis driver med, men vi vurderte å sjekke inn noe data i et repo som aldri kommer til å få noe bygg eller lignende, men Github sa nei takk. Like greit, tenker jeg.

Har ikke noen regel for hva som er for stort, tar det på magefølelsen. Men jeg tipper at magen reagerer et sted mellom 100kb og 1MB 🙂

Dvs, det kommer litt an på hva slags fil. Jeg godtar nok lettere noen MB på et bilde enn på en tekstfil.

Vi har flere TB data i VCS. Men for spill er Perforce de facto standard pga. støtte for mange store binaries.

https://dvc.org fungerte også ganske bra på enorme dataset for ML/data science.

> Dvs, det kommer litt an på hva slags fil. Jeg godtar nok lettere noen MB på et bilde enn på en tekstfil. Og hva med SVG-bilder da? 😃

SVG er "bare" XML 😊

Ja, det anser jeg som en tekstfil. En av de store styrkene med svg 😊

Men SVG-bildet ser misunnelig på PNG fordi den må vokse mye større.

Det med vektor og raster filformater er egentlig en del mer komplisert og interessant enn en skulle tro, spesielt komprimeringsalgoritmer. https://youtube.com/playlist?list=PLplnkTzzqsZTfYh4UbhLGpI5kGd5oW_Hh&si=qsBL84jgs9IwpgRE er veldig bra. Episoder 3 og 4 om raster images er relevant til diskusjonen.

Nope, men har hatt lyst til å prøve! Jeg bruker Emacs med Vim-keybindings fra dag til dag, og bruker nvim når jeg skal redigere småting fra terminal. Men jeg har aldri gått forbi default-configen til nvim. Det er mye jeg liker med nvim. • Kjapp å starte, kjapp å kjøre • Virker som de som lager nvim er bra folk • De tar 2024 seriøst, men prøver også å bidra med patcher tilbake inn i Vim • Har godt inntrykk av lua

Hva med deg? Bruker du nvim til alt?

Emacs kan også være kjapp å starte 😅 vår gamle config var treig, den nye starter på 3-4 sekunder.

Forøvrig har nylig vim-bruker @U06P2F094Q0 dyppet tærne i Emacs, og fikk etter mitt inntrykk et godt førsteinntrykk, ihvertfall av Clojure-i-Emacs

"Eight Megabytes of ram And Constantly Swapping"? 😁 (åtte MB RAM teller kanskje ikke som "mye" nå lenger...)

Jeg har kommet godt på vei å ha en Clojure config i nvim. Jeg elsker nvims modes og intuitive keybindings og den raskheten man får, men er nysgjerrig på hvordan emacs oppfører seg og hvilken forskjell det gjør, at det er et faktisk enkeltstående GUI program. Vet ingenting om emacs fra før andet enn at man bruker mye mer ctrl 😅

Savnet også et ferdig snekret clojure miljø så jeg kan få fart på å utvikle i clojure

Nå har jeg da bare trøbbel med å lære meg emacs og finne ut hvilke kommandoer jeg skal bruke. Prøver meg fram med Doom emacs (vim bindings FTW), men det kommer til å ta litt tid å vende seg til 😄

Synes ikke at det bare er startup'en som er treig, men vet ikke om det kan justeres :man-shrugging:

@U06P2F094Q0 Hvilken package manager bruker du? Og hvordan ser setupen din ut sånn grovt?

Jeg bruker lazy og conjure med parinfer og nvim-treesitter-sexp. https://github.com/TheBoosja/nvim/blob/main/lua/plugins/clojure.lua

Jeg bruker også nvim til alt 🙂 Kan definitivt anbefale conjure