Fossil versus Git • Hacker News Board

Re: Fossil versus Git

#191

Post by WirelessGigabit » Sun, Sep 24, 2023, 4:32 PM UTC

Groxx wrote: post #94

tux1968 wrote: post #84

Earlier quoted context omitted.

Git gets its bias from the Linux kernel development. When you're sharing your source changes with external people, who need to review your code, it just makes sense to present it in a clean, logical progression of changes. To wit, remove unnecessary noise like your development missteps. And it's only in that context that the emphatic call for history rewriting is born. Meaning, you can use all the power of Git to rec…

It's also useful in code reviews in general - I don't care about your development noise, and every single person in the future does not need to read it to understand the final result either. Rebases solve that: present a coherent story for easy understanding, rather than the messy reality. When you're purely local, sure - do whatever the heck you want. Nobody cares. But messy merges are rough for collaboration, both…

My largest problem about rebasing a branch onto master as a single commit is that it becomes harder to do provenance.

When the tip of my branch gets built (1) and the merge target is not ahead (2) I can actually retag the output of the build of the branch as what is now on master.

When you do a squash, while the default commit message contains the SHA, it no longer carries a semantical meaning. It's just a string of text.

Re: Fossil versus Git

#192

Post by Groxx » Sun, Sep 24, 2023, 5:03 PM UTC

mgaunard wrote: post #44

Culonavirus wrote: post #35

Earlier quoted context omitted.

Not in gamedev where you can have hundreds of gigs of art assets (models, textures, audio...), but you still want to version them or even have people working on them at the same time (maps...). But that is a different can of worms entirely.

git is for when you want to track changes to part of a file. In your scenario, you just want to track different versions of a file.

You can equally say that git is for when you want to track changes. And then it's a failing of git.

Besides, what's the difference? It's a file. The contents changed. Git doesn't say anything at all along the lines of "30% or more different means it's not a good fit for git".

Re: Fossil versus Git

#193

Post by Groxx » Sun, Sep 24, 2023, 5:08 PM UTC

sausagefeet wrote: post #173

nightfader wrote: post #49

Earlier quoted context omitted.

Because git excels in relatively small size text files and patching and difficult. You can't binary blobs like jpegs, audio, video easily.

But that's my point: why can't a version control system be good for this as well? It's the same thing underneath. Why do we have to split these different use cases across different tools and hope a foreign key constraint holds?

We've got lots of disk-backup tools that handle this just fine, deduplicating blocks and compressing where they're able.

Re: Fossil versus Git

#194

Post by unnouinceput » Sun, Sep 24, 2023, 5:55 PM UTC

SQLite wrote: post #182

unnouinceput wrote: post #45

Lacks (2020) in title. This article is written in Feb. 2020.

The document first appeared 2010-11-11. The latest change was on 2023-05-10. See https://www.fossil-scm.org/home/finfo/www/fossil-v-git.wiki for a complete change history for the document - including changes on branches. Aside: How would you get this information (the complete change history in a single file of a larger project) if the repository was on GitHub? Helpful hint: Click two nodes on the graph to see a diff…

Personally I read the article. It has, in the last chapter, the following: " As of this writing in February 2020...", so yeah, written by the author.

Re: Fossil versus Git

#195

Post by mgaunard » Mon, Sep 25, 2023, 7:55 PM UTC

Groxx wrote: post #192

mgaunard wrote: post #44

Earlier quoted context omitted.

git is for when you want to track changes to part of a file. In your scenario, you just want to track different versions of a file.

You can equally say that git is for when you want to track changes . And then it's a failing of git. Besides, what's the difference? It's a file. The contents changed. Git doesn't say anything at all along the lines of "30% or more different means it's not a good fit for git".

You can certainly use git, but then the model used to apply patches from different branches doesn't work for binary blobs.

So all the things that git specializes in are actually things you don't want.

Re: Fossil versus Git

#196

Post by mgaunard » Mon, Sep 25, 2023, 7:57 PM UTC

remram wrote: post #171

prepend wrote: post #159

Earlier quoted context omitted.

I disagree. Im sure fossil designers don’t want the whole thing to break if the wiki breaks, but have you tested it? I don’t know what dependencies it has or how well it’s designed. Im not worried about it being turned off. I’m worried about a bug in the wiki portion killing the “important” version. But my argument is that I don’t want my important thing I care about doing unimportant things I don’t care about. I lov…

Do you use all of Git's features? Bundles, emailing, git-daemon? Submodules? I wonder if you were aware that git contains an IMAP client.

git can send and receive data using multiple protocols; email is just one of them.

Re: Fossil versus Git

#197

Post by Groxx » Mon, Sep 25, 2023, 9:41 PM UTC

mgaunard wrote: post #195

Groxx wrote: post #192

Earlier quoted context omitted.

You can equally say that git is for when you want to track changes . And then it's a failing of git. Besides, what's the difference? It's a file. The contents changed. Git doesn't say anything at all along the lines of "30% or more different means it's not a good fit for git".

You can certainly use git, but then the model used to apply patches from different branches doesn't work for binary blobs. So all the things that git specializes in are actually things you don't want.

That seems like an implementation detail that could change tomorrow, at which point it could be perfectly fine to store large blobs in your repository, yea?

I completely agree Git is bad at this now, to be clear. I've watched single-file repositories bloat to hundreds of gigabytes due to lots of commits to a single 1MB file. But that doesn't seem like a design problem, just implementation.