←back to thread

848 points thefilmore | 3 comments | | HN request time: 0.618s | source
Show context
bandrami ◴[] No.43969975[source]
Pretty cool that Linus Torvalds invented a completely distributed version control system and 20 years later we all use it to store our code in a single place.
replies(29): >>43969999 #>>43970002 #>>43970008 #>>43970018 #>>43970019 #>>43970028 #>>43970031 #>>43970032 #>>43970036 #>>43970037 #>>43970142 #>>43970154 #>>43970198 #>>43970282 #>>43970314 #>>43970343 #>>43970418 #>>43970419 #>>43970431 #>>43970434 #>>43970451 #>>43970472 #>>43970541 #>>43970904 #>>43971268 #>>43971299 #>>43971387 #>>43971586 #>>43988717 #
SCdF ◴[] No.43970018[source]
I get what you're saying, but tbf hosting on github doesn't (yet!) box you out of just moving back to that system. It's still just git. It's still distributed, in the sense that if github goes down you could still generate patches and email them around, and then push back to github when it's back.

Everything surrounding code: issues, CICD, etc, is obviously another story. But it's not a story that is answered by distributed git either. (though I would love a good issue tracking system that is done entirely inside git)

replies(9): >>43970039 #>>43970120 #>>43970143 #>>43970151 #>>43970180 #>>43970299 #>>43970301 #>>43970480 #>>43970514 #
account-5 ◴[] No.43970151[source]
This is why I like fossil, it comes with most of the stuff I use built in, and you can deploy it as a website too. Use it for all of my personal projects and used it extensively for coursework at university.
replies(1): >>43971110 #
1. int_19h ◴[] No.43971110[source]
The annoying thing about Fossil is that it doesn't let you squash commits, not even in your private branches - they have some kind of philosophical point about that.

If you happen to agree with it, then yeah, it's great. If you like to commit quick and dirty and then tidy it up by squashing into logically complete and self-consistent commits, too bad.

replies(1): >>43971495 #
2. account-5 ◴[] No.43971495[source]
I can certainly see the appeal of having neat commits but I tend not to worry about them. On a couple of occasions, with my university writing, having a immutable history helped me figure out, for example, how something had ended up in a final draft without citation. I'd deleted the citation which was a quick URL paste in a comment block in an earlier draft, and I'd never saved it to zotero. If I'd been able to tidy up my commits I'd likely have lost it completely.
replies(1): >>43971657 #
3. int_19h ◴[] No.43971657[source]
The appeal depends on how messy your commits are to begin with. When you know that commit history can be rewritten later, it suddenly becomes okay to commit incomplete code that doesn't properly run or even build, effectively using git as an undo system with branching. But the resulting history is completely unsuitable for any future attempt to use `git blame` and such.