A pure JavaScript implementation of Git for Node and browsers

Post by guessmyname » Wed, May 16, 2018, 10:27 PM UTC

jordigh wrote: post #67

dfabulich wrote: post #11

Earlier quoted context omitted.

IMO, this is because there's a general attitude about porting to Rust that porting to Rust, by itself, makes a material improvement in the quality of the software (e.g. reliability, performance, readability), and that these improvements that can't be achieved in C/C++. Entrenched C developers then rise to the debate to defend their language. This debate has happened often enough that any time someone ports something…

The only attack I feel is calling C/C++ a language. It's two languages and we don't like each other very much. People who spend a lot of time trying to write good C++ avoid much of C's bread and butter like malloc and free, and the general hatred of C++ from C developers is well-documented. I happen to prefer C++ to C and D to both.

Post by goatlover » Wed, May 16, 2018, 10:31 PM UTC

TAForObvReasons wrote: post #20

kbenson wrote: post #10

I think it's interesting how there's two phenomena that seem to be related to me that get posted here and seem to get treated with different responses. One the one hand, we have software originally written in C/C++ being rewritten in Rust (not often, sometimes just conceptualized), and there's often a real push back by some people about how it's a waste and not useful. On the other, we have software rewritten in Java…

Without being too reductive, a JS implementation of anything represents new possibilities (running in the web browser or other environments), whereas a rust port doesn't expand the surface area. To give a comparison, critiques of rust ports are similar to the critiques of porting everything to node.js a few years ago -- most of the benefit comes from rewriting and applying lessons learned from the existing implementa…

Post by robertkrahn01 » Wed, May 16, 2018, 10:45 PM UTC

AntiRush wrote: post #25

There's a pretty full functioning project from several years ago (seems actively maintained) that has similar goals here: https://github.com/creationix/js-git I think it was initially crowdfunded.

Post by krupan » Wed, May 16, 2018, 10:47 PM UTC

bb88 wrote: post #58

bartread wrote: post #40

Earlier quoted context omitted.

It's really strange to me that nowadays source control seems to be, largely, a monoculture. Back in the day I either used, or knew plenty of people using any of CVS, Subversion, Sourcesafe, Sourcegear Vault, Perforce, AccuRev, ClearCase, along with a few others. Whilst distributed version control is a huge leap forward over many of those older systems, it's odd that nowadays it seems to be git or, well, nothing. I'm…

In Mercurial (circa 2016) Tags and branches were stored inside the repo itself, which meant you had to switch to the master branch to create a new branch or create a tag. If you created a tag in a branch the tag was visible only when you were in that branch. It caused numerous headaches trying to figure out why a tag didn't get pushed upstream. Git correctly treats this as metadata and stores it outside of the source…

Post by lsiebert » Wed, May 16, 2018, 11:18 PM UTC

krupan wrote: post #77

bb88 wrote: post #58

Earlier quoted context omitted.

In Mercurial (circa 2016) Tags and branches were stored inside the repo itself, which meant you had to switch to the master branch to create a new branch or create a tag. If you created a tag in a branch the tag was visible only when you were in that branch. It caused numerous headaches trying to figure out why a tag didn't get pushed upstream. Git correctly treats this as metadata and stores it outside of the source…

Your description is correct for tags, a little off for branches. You don't have to switch to master to create a branch, you have to switch to the branch you want to branch off of, which is the same as git. Also, all branches are visible and accessible from any branch/revision, unlike tags.