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

121–130 of 197 posts

Re: Fossil versus Git

#121

Post by thfuran »

mgaunard wrote: post #23
dognotdog wrote: post #2

I keep coming back to fossil again and again, despite git having a huge pull because of the easy publishing and collab on github/gitlab. Just the other day I was starting an exploratory project, and thought: I'll just use git so I can throw this on github later. Well, silly me, it happened to contain some large binary files, and github rejected it, wanting me to use git-lfs for the big files. After half an hour of no…

if you have large files in your repository, you have a design problem.

That's a ridiculous claim. Can you really not think of a single situation in which it makes sense to keep track of big pieces of data alongside (or even instead of) source code? The fact that many VCS don't handle large binary data nicely doesn't mean there's never a good reason to do so.

Re: Fossil versus Git

#122

Post by pama »

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 occasionally used to start a sync, go get coffee, chat with colleagues, read and answer my morning email, browse the arxiv, and then wait a few more minutes before I could touch the repo. In retrospect, I should have setup a cron job for it all, but it wasn’t always that slow and I liked the coffee routine. We switched to git. Git is just fast. Even cloning huge repos is barely enough time for grabbing a coffee from down the hall.

Re: Fossil versus Git

#123

Post by revertmean »

GuB-42 wrote: post #91
idiot900 wrote: post #72

If Fossil is so against deleting commits, what do you do if you've accidentally committed sensitive information that cannot live in any form in the repo?

It is a problem in all decentralized systems. Once you publish something, there is no going back. Anyone of your peers can decide to leave with your sensitive data. That's also what make them so resistant to data loss. Now if you know everyone who has a copy of your repository, you can have them run a bunch of sqlite commands / low level git commands to make sure that the commit is gone. If you didn't publish anythin…

> your best bet is to make an entirely new clone

Or you can just rebase to edit the commits and remove the secret file. If you're really paranoid you can run `git gc` vto ensure the object file is cleaned up also. If you're super paranoid, then you can do:

git hash-object secretpassword.txt

And check that hash isn't an object in the `.git/objects` directory.

Re: Fossil versus Git

#124

Post by Supermancho »

tux1968 wrote: post #103
appplication wrote: post #97

Earlier quoted context omitted.

It feels like overindexing on git as a source of truth for the iterative development process itself is just bikeshedding. Do whatever you want to do locally, then squash your commits into a single unit change. Document that comprehensively in your commit message for that squashed change. If there was some profound learning that feels like it needs rebase history for, just explain it narratively. Perhaps a more conten…

> squash your commits into a single unit change. Again, Git gets its bias from Linux kernel development. You can not present your entire work as a single unit change to sub-system maintainers for inclusion in the mainline. You can use the power of Git to present it in a digestible way that aids understanding, and allows piecemeal selection of acceptable bits, and rejection of others. This is clearly not relevant to e…

> to suggest there is no value at all, is laughable.

It can have no value at all to common workflows. Usually, this kind of singular change consideration is done at the PR level in another tool (github), which is divorced from git. Being able to present missteps/demonstrate specific commits where something didn't work (without another developer having to write the scenario) has utility that I have leveraged.

Re: Fossil versus Git

#125

Post by thfuran »

probably_wrong wrote: post #95
wirrbel wrote: post #18

I once tried it and ended up losing the history for some weird reason. Maybe its a fixed bug by now, but if I don't want to use git, I will use mercurial.

I lost all of my changes the first time I used git, which was the same time I found the error "cannot merge because you have unmerged files" (cut to me yelling "I know, that's why I want to merge!"). I have not yet forgiven git for that, but I'll reluctantly accept that me not knowing how to use the tool is not entirely the tool's fault. Also: I stand 100% by your alternative solution because Mercurial rocks.

I'm sad that mercurial lost the vcs war.

Re: Fossil versus Git

#126

Post by twic »

moojd wrote: post #78
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…

I like that git allows rebase, as long as it is only done in prs or local. Rebase in the sheets, merge in the streets.

Or, more conventionally put:

> The golden rule of git rebase is to never use it on public branches.

https://www.atlassian.com/git/tutorials/merging-vs-rebasing#...

If you're doing trunk based development, with continuous integration, then you're approximately always on a public branch, and rebasing is not very useful.

Re: Fossil versus Git

#127

Post by prepend »

rakoo wrote: post #104
prepend wrote: post #30

Earlier quoted context omitted.

Wouldn’t it be great if my car also brewed coffee? I drink coffee every day on the way to work. I’m always in a hurry. It would be convenient to just build that in. I always drink coffee while driving, I may as well just build it in. Cut to a month later because my car won’t start because I’m out of coffee grounds. This is how fossil seems to me. I probably have hundreds of repos with just versioned files. That’s it.…

> And when I do, I can trivially push my repo to GitHub or gitlab or sr.ht or whatever. And not the wiki, the issues, the releases, the forums, the website, and all that stuff that is probably needed once your project starts to involve a few people.

First, those are bolt-ons and I don’t actually want them tied to the source code management system.

Second, for my repos, I use markdown directly in the repo instead of a wiki. This works better for me because the version history is in the repo and for wikis the author is important context for the value of the information.

Third, I build my website using an ssg that builds off my repo. Typically this is Jekyll scripts that build out fine on GitHub pages or gitlab pages or whatever. And I can move to any host I want. I don’t want to couple my project’s web site to my source code host.

These are “solved” features as far as I’m concerned and these actually bring negative value for me. I don’t want to worry about what kind of forum functionality my scm provides. And I certainly don’t care about pushing my forum from one server to another.

Re: Fossil versus Git

#128

Post by prepend »

remram wrote: post #107
prepend wrote: post #30

Earlier quoted context omitted.

Wouldn’t it be great if my car also brewed coffee? I drink coffee every day on the way to work. I’m always in a hurry. It would be convenient to just build that in. I always drink coffee while driving, I may as well just build it in. Cut to a month later because my car won’t start because I’m out of coffee grounds. This is how fossil seems to me. I probably have hundreds of repos with just versioned files. That’s it.…

> my car won’t start because I’m out of coffee grounds I'd call this a straw man but it's way past that...

It’s an allegory, not a strawman.

Re: Fossil versus Git

#129

Post by prepend »

Skinney wrote: post #114
prepend wrote: post #30

Earlier quoted context omitted.

Wouldn’t it be great if my car also brewed coffee? I drink coffee every day on the way to work. I’m always in a hurry. It would be convenient to just build that in. I always drink coffee while driving, I may as well just build it in. Cut to a month later because my car won’t start because I’m out of coffee grounds. This is how fossil seems to me. I probably have hundreds of repos with just versioned files. That’s it.…

If your car followed the unix philosophy you’d have to bring your own radio and AC.

Right. It’s a careful balance of what to include and what not to include.

I don’t know the exact dividing line for “do one thing” but I think that modularity and composability is important.

I like having an AC in my car. But I don’t want AC to be a dependency for my car.

I like chaining tools together, but work to minimize the required dependency among tools.

I think in principle, it’s good if you can install components separately. So for me git only doing version control is good. If they added a chat feature, I would not want that. If they had a chat module that I could optionally install, maybe.

Re: Fossil versus Git

#130

Post by prepend »

fmajid wrote: post #109
prepend wrote: post #17

Earlier quoted context omitted.

It is extremely rare that I have a file over 100MB. I also think it’s one of those situations where if I have a giant binary file in source control “I’m doing it wrong” so git helps me design better. It’s like in the olden days when you couldn’t put blobs directly in a row so databases made you do your file management yourself instead of just plopping in files. I like git. I don’t like giant binary files in my commit…

In the age of Large Language Models, large blobs will become the rule, not the exception. You’re not going to retrain models costing $100M to build from scratch because of the limitations of your SCM.

I don’t store those in my scm. It’s not a limitation of my scm that I can’t store a 20gig model directly in the repo.

So you’re right, I’m not going to retrain models costing $100M because of SCM limitations. That’s because I don’t have any SCM limitations.

Post reply on HN