Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I made my own Git

tonystr.net

Post reply on HN
Print view View original

131–140 of 184 posts

Re: I made my own Git

#131

Post by below43 »

nerdponx wrote: post #38
TonyStr wrote: post #27

Earlier quoted context omitted.

Interestingly, I looked at github insights and found that this repo had 49 clones, and 28 unique cloners, before I published this article. I definitely did not clone it 49 times, and certainly not with 28 unique users. It's unlikely that the handful of friends who follow me on github all cloned the repo. So I can only speculate that there are bots scraping new public github repos and training on everything. Maybe tha…

Time to start including deliberate bugs. The correct version is in a private repository.

They used to do this with maps - eg. fake islands - to pick up when they were copied.

Re: I made my own Git

#132

Post by theLiminator »

speed_spread wrote: post #127
theLiminator wrote: post #125

Earlier quoted context omitted.

It's very cool though I imagine it's doa due to lack of git compatibility...

Lack of current-SCM incumbent compatibility can be an advantage. Like Linus decided to explicitly do the reverse of every SVN decision when designing git. He even reversed CLI usability!

I think the network effects of git is too large to overcome now. Hence why we see jj get a lot more adoption than pijul.

Re: I made my own Git

#133

Post by oconnor663 »

EdSchouten wrote: post #51
jrockway wrote: post #46

sha256 is a very slow algorithm, even with hardware acceleration. BLAKE3 would probably make a noticeable performance difference. Some reading from 2021: https://jolynch.github.io/posts/use_fast_data_algorithms/ It is really hard to describe how slow sha256 is. Go sha256 some big files. Do you think it's disk IO that's making it take so long? It's not, you have a super fast SSD. It's sha256 that's slow.

It depends on the architecture. On ARM64, SHA-256 tends to be faster than BLAKE3. The reasons being that most modern ARM64 CPUs have native SHA-256 instructions, and lack an equivalent of AVX-512. Furthermore, if your input files are large enough that parallelizing across multiple cores makes sense, then it's generally better to change your data model to eliminate the existence of the large inputs altogether. For exa…

As far as I know, most CDC schemes requires a single-threaded pass over the whole file to find the chunk boundaries? (You can try to "jump to the middle", but usually there's an upper bound on chunk length, so you might need to backtrack depending on what you learn later about the last chunk you skipped?) The more cores you have, the more of a bottleneck that becomes.

Re: I made my own Git

#134

Post by chungy »

toyg wrote: post #40
smartmic wrote: post #10

Earlier quoted context omitted.

I use Fossil extensively, but only for personal projects. There are specific design conditions, such as no rebasing [0], and overall, it is simpler yet more useful to me. However, I think Fossil is better suited for projects governed under the cathedral model than the bazaar model. It's great for self-hosting, and the web UI is excellent not only for version control, but also for managing a software development proje…

Sounds like a more modern cvs/Subversion

It was developed primarily to replace SQLite's CVS repository, after all. They used CVSTrac as the forge and Fossil was designed to replace that component too.

Re: I made my own Git

#135

Post by brendoncarroll »

DASD wrote: post #107
brendoncarroll wrote: post #97

Me too. Version control is great, it should get more use outside of software. https://github.com/gotvc/got Notable differences: E2E encryption, parallel imports (Got will light up all your cores), and a data structure that supports large files and directories.

Nice! Not sure if you're aware of Got(Game of Trees) that appears to pre-date your Got. https://gameoftrees.org/index.html

Yes the author reached out. There has not yet been a confusion among real users that I am aware of.

https://github.com/gotvc/got/issues/20

Re: I made my own Git

#137

Post by oconnor663 »

grumbelbart2 wrote: post #48
jrockway wrote: post #46

sha256 is a very slow algorithm, even with hardware acceleration. BLAKE3 would probably make a noticeable performance difference. Some reading from 2021: https://jolynch.github.io/posts/use_fast_data_algorithms/ It is really hard to describe how slow sha256 is. Go sha256 some big files. Do you think it's disk IO that's making it take so long? It's not, you have a super fast SSD. It's sha256 that's slow.

Is that even when using the SHA256 hardware extensions? https://en.wikipedia.org/wiki/SHA_instruction_set

It's mixed. You get something in the neighborhood of a 3-4x speedup with SHA-NI, but the algorithm is fundamentally serial. Fully parallel algorithms like BLAKE3 and K12, which can use wide vector extensions like AVX-512, can be substantially faster (10x+) even on one core. And multithreading compounds with that, if you have enough input to keep a lot of cores occupied. On the other hand, if you're limited to one thread and older/smaller vector extensions (SSE, NEON), hardware-accelerated SHA-256 can win. It can also win in the short input regime where parallelism isn't possible (< 4 KiB for BLAKE3).

Re: I made my own Git

#138

Post by iberator »

p0w3n3d wrote: post #75
nasretdinov wrote: post #37

Nice work! On a complete tangent, Git is the only SCM known to me that supports recursive merge strategy [1] (instead of the regular 3-way merge), which essentially always remembers resolved conflicts without you needing to do anything. This is a very underrated feature of Git and somehow people still manage to choose rebase over it. If you ever get to implementing merges, please make sure you have a mechanism for re…

That's something new to me (using git for 10 years, always rebased)

I'm even more lazy. I almost always clone from scratch after merging or after not touching the project for some time. So easy and silly :)

I always forget all the flags and I work with literally just: clone, branch, checkout, push.

(Each feature is a fresh branch tho)

Re: I made my own Git

#139

Post by pyrolistical »

arunix wrote: post #54
nasretdinov wrote: post #37

Nice work! On a complete tangent, Git is the only SCM known to me that supports recursive merge strategy [1] (instead of the regular 3-way merge), which essentially always remembers resolved conflicts without you needing to do anything. This is a very underrated feature of Git and somehow people still manage to choose rebase over it. If you ever get to implementing merges, please make sure you have a mechanism for re…

I remember in a previous job having to enable git rerere, otherwise it wouldn't remember previously resolved conflicts. https://git-scm.com/book/en/v2/Git-Tools-Rerere

Would be nice if centralized git platforms shared rerere caches

Re: I made my own Git

#140

Post by ezst »

nasretdinov wrote: post #37

Nice work! On a complete tangent, Git is the only SCM known to me that supports recursive merge strategy [1] (instead of the regular 3-way merge), which essentially always remembers resolved conflicts without you needing to do anything. This is a very underrated feature of Git and somehow people still manage to choose rebase over it. If you ever get to implementing merges, please make sure you have a mechanism for re…

On recursive merging, by the author of mercurial

https://www.mercurial-scm.org/pipermail/mercurial/2012-Janua...

Post reply on HN