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

Fossil versus Git

fossil-scm.org

Post reply on HN
Print view View original

81–90 of 197 posts

Re: Fossil versus Git

#81

Post by maccard »

nightfader wrote: post #25

The whole point that git rejects large blobs is primarily because they don't belong in VCS. But for those who need large blobs there is git-lfs as the author mentioned. I don't see a problem with that approach because I personally don't like my git repos growing large after just a few commits which then takes up time for huge clones by other devs. This is the whole principle behind monorepos. If going the monorepo ro…

> The whole point that git rejects large blobs is primarily because they don't belong in VCS.

Who are you to say that my blobs don't belong in version control? Where does a versioned asset file for a website or a game go, if not in version control? If the answer is "somewhere else referneced by the git commit", then you're accepting that the data belongs in version control but that git can't handle it.

> But for those who need large blobs there is git-lfs as the author mentioned.

git-lfs isn't git, though. It's a bodge on top of git that breaks many of the assumptions about git, requires special handling and setup. If it _were_ a core part of git I would agree, but it's not.

> So I prefer gits Unix philosophy of doing one thing but doing it really well

Git is tightly coupled to a _bunch_ of unix tools, and doesn't work without them. Try running git on windows and see that installs an entire suite of posix tools (msys) just to let you run `git clone`.

Re: Fossil versus Git

#82

Post by maccard »

afiori wrote: post #67
ghosty141 wrote: post #48

Earlier quoted context omitted.

So how would you version a game that needs assets? These files must be versioned but can be very big, for example long cutscene videos. Some projects need the ability to version big files, there is a good reason why perforce exists and is widely used in the gaming industry.

I am not saying that it is a better UX, but hashed/versioned blobs on S3 would mostly work depending on tooling integration.

That's building a custom version control on top of the version control you're already using.

Re: Fossil versus Git

#83

Post by beebeepka »

nightfader wrote: post #56
ChrisMarshallNY wrote: post #51

Earlier quoted context omitted.

That's why Perforce is still the SCM of choice for a lot of creatives. I don't know if they still do it, but Unreal used to ship a Perforce license with their SDK.

That's also why perforce is slow as heck unless you throw massive resources at it. I also work in the chip industry BTW.

I've only used Perforce for two years and it didn't feel slow at all. The company wasn't exactly throwing money at hardware.

Re: Fossil versus Git

#84

Post by tux1968 »

Supermancho wrote: post #40

A large number of Fossil positives are related to not having rebase. It feels like this is a huge concern for functionality that many people, do not use that often. The last time I used rebase at a job was maybe 5 years ago? Other than that my bigger gripe is when I read something like this: > Git strives to record what the development of a project should have looked like had there been no mistakes Git does not striv…

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 record all your changes as you proceed through development, and then rebase them into something presentable for the greater world.

Re: Fossil versus Git

#85

Post by mbivert »

Vinnl wrote: post #15
maegul wrote: post #4

Earlier quoted context omitted.

Well, do you use GitHub or an equivalent? The point of this, as the article states: > These additional capabilities are available for Git as 3rd-party add-ons, but with Fossil they are integrated into the design, to the point that it approximates "GitHub-in-a-box. I’ve not used fossil, but I appreciate this idea. Sure, it’s not unixy, but maybe a VCS reasonably demands such features, and today, it’s not as though the…

To clarify the actual benefit: this means that tickets, etc. are also distributed, i.e. available and backed up locally with every contributor, and not dependent on lock-in to a single vendor like GitHub. Edit: and yes, of course there are downsides as well. It's up to you to weigh them against each other.

Versioning/distributing tickets is indeed useful; but can't this be "implemented" in git already, by defining a file-based format (think, issue/$YYYYMMDDHHMMSS-$title.md, but the variants are endless), and versioning those files?

A first drawback I can think of is that this would probably require an additional layer for non-tech people. I haven't had the opportunity to use Fossil, so I am clueless regarding the kind of UI they propose, but I wouldn't be surprised that they actually solve this, considering the extensive list of features.

Re: Fossil versus Git

#86

Post by bachmeier »

mgaunard wrote: post #21

Stopped reading at first point; why would I want my versioning system coupled to a bunch of random services? Doing one thing and one thing only is a feature, not a bug.

I always find it weird when someone says this. Does Git do only one thing? Sure, for the appropriate definition of "one thing". But then so does Fossil if you define the "one thing" to be managing a software project.

Re: Fossil versus Git

#87

Post by hn92726819 »

mbivert wrote: post #85
Vinnl wrote: post #15

Earlier quoted context omitted.

To clarify the actual benefit: this means that tickets, etc. are also distributed, i.e. available and backed up locally with every contributor, and not dependent on lock-in to a single vendor like GitHub. Edit: and yes, of course there are downsides as well. It's up to you to weigh them against each other.

Versioning/distributing tickets is indeed useful; but can't this be "implemented" in git already, by defining a file-based format (think, issue/$YYYYMMDDHHMMSS-$title.md, but the variants are endless), and versioning those files? A first drawback I can think of is that this would probably require an additional layer for non-tech people. I haven't had the opportunity to use Fossil, so I am clueless regarding the kind…

Well the article does say:

> These additional capabilities are available for Git as 3rd-party add-ons, but with Fossil they are integrated into the design

Re: Fossil versus Git

#88

Post by bradley13 »

bloopernova wrote: post #64
Supermancho wrote: post #40

A large number of Fossil positives are related to not having rebase. It feels like this is a huge concern for functionality that many people, do not use that often. The last time I used rebase at a job was maybe 5 years ago? Other than that my bigger gripe is when I read something like this: > Git strives to record what the development of a project should have looked like had there been no mistakes Git does not striv…

Regarding rebase, it's been my experience that among many developers rebase has a mythical status. You're "supposed to" rebase, but no one knows the benefit of doing so. It's a big downside of git being treated like some magical difficult spell. Same with exiting Vim, people treat it as way harder than it really is.

I tend to agree. I haven't used Git in a large project, but...why would I want to rewrite history? The project is what it is. What happened, happened. If there are a couple of weird commits, who cares? At most, maybe edit the commit messages to explain.

Re: Fossil versus Git

#89

Post by [deleted] »

bradley13 wrote: post #3

I don't know Fossil. However, the first entry in the comparison table puts me off. "VCS, tickets, wiki, docs, notes, forum, chat, UI, RBAC" I don't want my version control system to be a wiki. Or a chat app, or any of that.

[deleted]

Re: Fossil versus Git

#90

Post by [deleted] »

mgaunard wrote: post #21

Stopped reading at first point; why would I want my versioning system coupled to a bunch of random services? Doing one thing and one thing only is a feature, not a bug.

[deleted]
Post reply on HN