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

What comes after Git

matt-rickard.com

Post reply on HN
Print view View original

201–210 of 430 posts

Re: What comes after Git

#201

Post by eternityforest »

I'm perfectly happy with Git. In the most basic uses, it's extremely easy, get git cola and you're done. The advanced uses are harder than they need to be, but not by that much. There's always google.

I wish it had native zip and sqlite support, I'd love to see issues and PRs more integrated, but that's about it.

It would be nice to have an unversioned sync directory in a repo, that could be updated without a commit and had no history, for implementing fast-changing stuff where history isn't critical, like stashing log files right on an internal config repo. But that's not exactly necessary.

I'm sure better things could be done. But would they be usable over ssh, no certs needed, as well as HTTP? Or would you need a domain name? Would they have decent GUIs? Would they still be decentralized? Would they have an equivalent to LFS? What features would they drop?

Would half the features be plugins so that every repo relied on a unique set of optional features?

I'm... not sure I'd like the kind of VCS that the current FOSS culture would like to make....

If people really tried to replace Git, could see multiple VCSes getting big at once. Git is pretty unique in how it is so popular, you probably don't need to know any others.

We can do better than git, but it's pretty unique. It's already a base primitive for so many things like package managers and notetaking. It's so deeply engrained in dev culture, it's almost like UTF-8, and I would hope whatever replaces it has that same property.

I think the easy solution would just be if the git devs themselves made a new first party front-end and added a few features.

There are lots of git frontends, that everyone ignores because you might as well just learn git, it's everywhere, but if some new git2 command was included and just as common, we could have a very smooth transition.

Re: What comes after Git

#202

Post by sgbeal »

sriku wrote: post #146

I've been using fossil ( https://fossil-scm.org ) for personal projects for like a decade now and I much prefer it over git. The characteristics that get me to stick with it are - 1. Single file executable. No dependencies to "install". Just the executable and you're good. 2. The whole repo is a single sqlite DB file. Fabulous for backups, sharing, hosting etc. 3. You cannot rewrite history unlike git. Hence the name…

(A long-time fossil dev here...)

Re. integrated wiki: when i first saw fossil (Christmas break of 2007) two features made it a killer app for me: wiki and hosting as a CGI. The wiki aspect has long since taken a back seat to the so-called "embedded docs" feature, where the docs live in the source tree and become first-class SCM citizens. However fossil is, to the best of my knowledge, still the only SCM which is absolutely trivial to host as a CGI, which means it can be hosted on cheap shared hosters just as easily as it can on one's standalone VPS.

As far as "what comes after git," though: git is the SCM needed by the 0.1% (or fewer) of the largest, most-active FOSS projects. Imagine the Linux kernel source tree if its SCM could not remove dead branches - it would quickly become uncloneable under all of that weight. Fossil is not designed to scale to projects of that size. Fossil is, however, an ideal SCM for that 98%+ of remaining projects which fall into the size categories of personal/small/medium.

Re: What comes after Git

#203

Post by ribit »

My main headache with git — which is absent from the list in the blog – is that it tracks snapshots instead of tracking changes. It's probably less of an issue for software developers where a "version" is what this all is about — after all, that's what you ship, but if you try to use version control in a context of academic writing or data analysis, it can become very difficult to track individual contributions. All git can do is to compare snapshots and allow you to impose a resemblance causal order onto them (which you can freely manipulate anyway with rebasing, squashing etc.). If your workflow consists of trying out many different ideas and then choosing which of them to keep and which to discard, git can be extremely painful — you either end up with a history that is a complete mess or waste a lot of time rebasing and reorganising the (fake anyway) order of snapshots.

That's why I am exited for tools like Pijul that attempt to actually track changes.

Re: What comes after Git

#204

Post by lucideer »

A lot of people responding (in good faith) to the premise of the title but not really engaging with the absolute nonsense points made within it.

Aside from it all being very vague, it struck me these are high level concepts and keywords the author seemed to have gleaned from experience working with knowledgeable peers but never quite grokked themselves. So it surprised me to read their open-source maintainer experience about page (though the professional experience being in Google does fit my original assumption).

> Atomicity accross projects

Git repos are as atomic as you make them. Github is not a defacto monorepo. The only people likely to use it as such are monorepo aficionados (Googlers?) who are deliberately avoiding atomicity. Also, Github isn't Git.

> Package management

Package managers already use checksums. This entire point is just wrong and ignorant. Reproducible builds would be nice here, sure, but outside of a few weird exceptions in dynamic builds we already have what the author wants here.

> Semantic diff

This would be great but... the author is an engineer right. How much have they thought about this? This would be a gargantuan undertaking. An awesome feature no doubt, but the maintenance effort...

> Merge queue data structure

The body of this bullet doesn't relate to the heading. I guess they're talking about how in-progress merges are stored on the FS but how would that impact testing (which the author rightfully points out is unrelated to VCS). What? This is just mashing unrelated jargon keywords together.

> Fan-out pull requests

Github is not Git.

> git should be fully decoupled from the pull request and merge workflow

Oh dear. Where is Drew Devault...

> lfs

The first good point they've made

> fossil

Yes fossil is cool. If the title of the post was "we should all use fossil" it would be more realistic.

Re: What comes after Git

#205

Post by xigoi »

tehbeard wrote: post #176
pydry wrote: post #160

Earlier quoted context omitted.

Knowledge of git has become a sort of status signifier. It "makes you a developer". I think for this reason there's a lot less pushback on its bad UX than there would be for any other program. It would render knowledge of its arcane guts less...special. The juniors will be forced to deal. It makes me wonder though, if needlessly arcane knowledge is and always was a part of other apprentice relationships.

How do you improve the ux though? I see a lot of complaints about it, and agree that for all the porcelain, you do have to become familiar with the plumbing to solve issues. But noones shown me a good alternate ux story, just different porcelain/fittings. I still have to reach under the sink because said new porcelain didn't stop/avoid a case sensitivity clash, or it barfed on a merge and left the repo still to merge…

Making the CLI self-consistent would be a big improvement.

Re: What comes after Git

#206

Post by sgbeal »

geenat wrote: post #190
sriku wrote: post #146

I've been using fossil ( https://fossil-scm.org ) for personal projects for like a decade now and I much prefer it over git. The characteristics that get me to stick with it are - 1. Single file executable. No dependencies to "install". Just the executable and you're good. 2. The whole repo is a single sqlite DB file. Fabulous for backups, sharing, hosting etc. 3. You cannot rewrite history unlike git. Hence the name…

How is large file support? What strategy is employed for binary file handling? How does it compare to git LFS / annex / mercurial? Aside from that, Fossil is very intriguing.

> How is large file support?

Fossil is, because of its sqlite dependency, limited to blobs no larger than 2GB each. Some of its algorithms require keeping two versions of a file in memory at once, so "stupidly huge" blobs are not something it's ideal for. Fossil is designed for SCM'ing source code, and source code never gets anywhere near 2GB per file. The only projects which use such files seem to be (based on fossil forum traffic) high-end games and similar media-heavy/media-centric projects which fossil is not designed for.

> What strategy is employed for binary file handling?

That's a vague question, so here's a vague answer: it handles binaries just fine and can delta them just fine. It cannot do automatic merging of binary files which have been edited concurrently by 2+ users because doing so requires file-format-specific logic. (AFAIK _no_ SCM can merge (as opposed to delta) binaries of any sort.)

Re: What comes after Git

#207

Post by sgbeal »

L3viathan wrote: post #193
sriku wrote: post #146

I've been using fossil ( https://fossil-scm.org ) for personal projects for like a decade now and I much prefer it over git. The characteristics that get me to stick with it are - 1. Single file executable. No dependencies to "install". Just the executable and you're good. 2. The whole repo is a single sqlite DB file. Fabulous for backups, sharing, hosting etc. 3. You cannot rewrite history unlike git. Hence the name…

1: What does it matter? I do $packagemanager install git and am done. What do I care whether it's got dependencies or consists of several binaries? 2: Fair enough. Although a multi-file backup doesn't sound hard to me either. 3: That would give me the opposite of peace of mind. I can't clean up my messy WIP commits? 4: Sounds like a nice feature. 5: This just uses the term "tag" to mean something else that git tags.…

> What does it matter? I do $packagemanager install git and am done.

_Freedom_. Fossil is trivial to build on all modern platforms and we (in the fossil project) always recommend that folks use the trunk version, building it for themselves. Depending on an OS'es package manager just means that one is stuck with whatever version that package repo's volunteer package maintainers post.

> I can't clean up my messy WIP commits?

Nope. Fossil remembers what happened, not what "should have" happened. We (on the fossil project) consider that a feature, and fossil's own history is littered with "oopsies" (no small percentage of them from yours truly).

Re: What comes after Git

#209

Post by geenat »

sgbeal wrote: post #206
geenat wrote: post #190

Earlier quoted context omitted.

How is large file support? What strategy is employed for binary file handling? How does it compare to git LFS / annex / mercurial? Aside from that, Fossil is very intriguing.

> How is large file support? Fossil is, because of its sqlite dependency, limited to blobs no larger than 2GB each. Some of its algorithms require keeping two versions of a file in memory at once, so "stupidly huge" blobs are not something it's ideal for. Fossil is designed for SCM'ing source code, and source code never gets anywhere near 2GB per file. The only projects which use such files seem to be (based on fossi…

Fair enough, like vanilla git as of today.

I do hope someday git and others employ either a git annex or mercurial-style scheme where if it's a large binary file: 1. no diff is performed, and 2. only the latest version is kept within the history.

This would blow wide open the possibilities for using Fossil in binary-heavy projects such as machine learning, games, simulation.

I could see the SQLite limitation worked around by just splitting up binary data into multiple pieces.

Re: What comes after Git

#210

Post by tasuki »

pdmccormick wrote: post #100

Am I the only one who thinks that Git's UX is fine, and maybe even rather enjoyable? It has taken time to learn, and I am by no means a power user, but its model is now in my brain so, for better or worse, it's how I think and work now too (interactive rebasing for the win, all the time, and lots of shell aliases to shorten things). I do wish I had an easier way to split up a commit that accidentally included several…

Git's UX sucks, but git is built on like four simple concepts (blobs, trees, commits, refs) and I feel that's almost impossible to improve on.
Post reply on HN