Remix.run Logo
SOLAR_FIELDS 11 hours ago

Every time I see a statement like this I wonder what specific features of git that people feel like are terrible enough that it’s time to completely start over. Besides “the UX is kinda shit and it’s confusing to learn”, which there are many solutions for already that don’t involve reinventing a pretty good wheel.

bluGill 11 hours ago | parent | next [-]

Coming from mercurial (which is older than git), git doesn't understand a branch. Instead of a branch you get a tag that moves, which is very different. Too often I'm trying to figure out where something came in, and but there is just a series of commits with no information of which commits are related. Git then developed the squash+rebase workflow which softof gets around this, but it makes commit longer (bad), and loses the real history of what happened.

Git was not the first DVCS, there were better ones even when it was made. But Linus pushed git and people followed like sheep.

(I'm using git, both because everyone else is, and also because github exists - turns out nobody even wants a DVCS, they want a central version control system with the warts of SVN fixed).

jcranmer 10 hours ago | parent | next [-]

> Coming from mercurial (which is older than git)

Git is older than mercurial by 12 days. Bazaar has git beat by about the same amount of time. The major DVCSes all came out within a month of each other.

> But Linus pushed git and people followed like sheep.

I don't think this is true. Until around 2010-2011 or so, projects moving to DVCS seemed to pick up not git but mercurial. The main impetus I think was not Linux choosing git but the collapse of alternate code hosting places other than GitHub, which essentially forced git.

sevenseacat 8 hours ago | parent [-]

way way back in the day I did some digging into all three - and picked bazaar for my personal projects. that didn't last long lol

em-bee 10 hours ago | parent | prev [-]

the lack of a proper branch history is also the main pain point for me. but i disagree that noone wants a DCVS. having a full copy of the history locally, and being able to clone from any repo to anywhere else and even merge repos (without merging branches) is a major win for me.

mhh__ 11 hours ago | parent | prev | next [-]

Git is basically fine even though the verbs are backwards - e.g. you shouldn't need to name branches, commits should be far more automatic, but the basic mechanisms are fine.

GitHub is an abomination.

dieortin 10 hours ago | parent [-]

You might already be aware, but jj fixes exactly those complaints you have with git

seanhunter 11 hours ago | parent | prev | next [-]

Right.

How we got git was cvs was totally terrible[1], so Linus refused to use it. Larry McEvoy persuaded Linus to use Bitkeeper for the Linux kernel development effort. After trying Bitkeeper for a while, Linus did the thing of writing v0 of git in a weekend in a response to what he saw as the shortcomings of Bitkeeper for his workflow.[2]

But the point is there had already been vcs that saw wide adoption, serious attempts to address shortcomings in those (perforce and bitkeeper in particular) and then git was created to address specific shortcomings in those systems.

It wasn't born out of just a general "I wish there was something easier than rebase" whine or a desire to create the next thing. I haven't seen anything that comes close to being compelling in that respect. jj comes into that bucket for me. It looks "fine". Like if I was forced to use it I wouldn't complain. It doesn't look materially better than git in any way whatsoever though, and articles like this which say "it has no index" make me respond with "Like ok whatever bro". It really makes no practical difference to me whether the VCS has an index.

[1] I speak as someone who maintained a CVS repo with nearly 700 active developers and >20mm lines of code. When someone made a mistake and you had to go in and edit the repo files in binary format it was genuinely terrifying.

[2] In a cave. From a box of scraps. You get the idea.

bombcar 11 hours ago | parent [-]

To be fair the "shortcomings" that spurred it on mainly were the Samba guys (or just one) reverse-engineering Bitkeeper causing the kernel free license getting pulled, which caused Linus to say "I can build my own with blackjack and pre-commit hooks" and then he did, addressing it toward his exact use case.

It gained tons of popularity mainly because of Linus being behind it; similar projects already existed when it was released.

xtracto 11 hours ago | parent [-]

Mercurial was there, was better and more complete.

Too sad it didnt win the VCS wars.

seanhunter 11 hours ago | parent [-]

When I tried both at that time hg was just really slow so I just adopted git for all my personal projects because it was fast and a lot better than cvs. I imagine others were the same.

bombcar 10 hours ago | parent [-]

I went with bzr mainly because it had an easy way to plugin "revision" into my documents in a way I could understand and monotonously increment.

hg was slow though I don't know how bzr compared as I was using it pretty light-weight.

l72 10 hours ago | parent | prev [-]

If git would change two defaults, that would make me really happy:

  1. git merge ONLY does merges (no fast forward/rebase). git pull ONLY does a fast forward
  2. git log by default is git log --first-parent. Just show commits where the parent is the current branch. This makes the merge workflow really easy to understand an linear, because in the end, you only care about commits on the trunk.