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

91–100 of 197 posts

Re: Fossil versus Git

#91

Post by GuB-42 »

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 anything, as someone else said, your best bet is to make an entirely new clone, transfer the work you did on the original, omitting the sensitive data, then nuke the original.

The difference seems to be that commits are serious business on fossil, and they encourage you to test before you commit. While on git, commits are more trivial, pushing is where things become serious.

Re: Fossil versus Git

#92

Post by RakutenSatori »

Didn't know about fossil. It's unfortunate many people are saying they stopped reading at the "fossil is everything into one" part because It still looks an interesting way of doing vcs.

> 95% of the code in SQLite comes from just four programmers, and 64% of it is from the lead developer alone. The SQLite developers know each other well and interact daily. Fossil was designed for this development model.

They propose it as a way to do development with few members who all know each other, rather than making an open repository for anyone on the Internet to contribute.

I want to try it now and see what does it bring on the table and whether it's a viable alternative to git in this regard.

Re: Fossil versus Git

#93

Post by snuxoll »

bradley13 wrote: post #88
bloopernova wrote: post #64

Earlier quoted context omitted.

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.

Because when I am developing in my local repo I have a stream of commits that go “adding xyz because abc is being a pain”. They’re informational for me as I progress through iterating on a feature, but when I’m ready to merge I really don’t want that mess polluting the global commit history. I may also be working on multiple things in parallel and want to isolate them from each other, both to keep a cleaner history but also for code review purposes.

There’s plenty of reason to use rebase, but if you’re fine letting the occasional mess slip into the history then it’s fine to NOT use it as well.

The one universal case though. Rebase before you submit a patchset for review. I don’t want to fight through merge conflicts to review a change, make sure it’s applied to the current HEAD before you send it.

Re: Fossil versus Git

#94

Post by Groxx »

tux1968 wrote: post #84
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 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 present and future.

(rough, not fundamentally wrong, to be clear. It's just a friction tradeoff, dealing with human behavior has next to no absolutes)

Re: Fossil versus Git

#95

Post by probably_wrong »

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.

Re: Fossil versus Git

#96

Post by goku12 »

bradley13 wrote: post #88
bloopernova wrote: post #64

Earlier quoted context omitted.

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.

There are a few legitimate cases where you want to rewrite history.

1. Assume you are a user who is cloning the master/main branch and building it. If that branch contains your development missteps, then you are in for a world of pain. We as users always assume that the master/main Head is always buildable (excluding inadvertent mistakes).

2. If you are sending the commits as patches, then it makes sense to include a complete feature in a single patch. It will otherwise be very hard for the reviewer to make sense of any patch.

Re: Fossil versus Git

#97

Post by appplication »

tux1968 wrote: post #84
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 rec…

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 contentious take: rebasing doesn’t bring any real value. To the original comment above, I would say a significant percentage of teams never use rebase and drive business value just fine. I do not think there exists and evidence to suggest teams that use rebase over squash merging are in some way higher performing. Rebase is something that some people’s obsessiveness compels them to care abut because they can, and then retroactively justify their decisions by suggesting value that isn’t there.

Re: Fossil versus Git

#98

Post by Kamq »

bradley13 wrote: post #88
bloopernova wrote: post #64

Earlier quoted context omitted.

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.

Usually it's if you committed something you shouldn't have.

You still have to change api keys if you ever pushed, because things like github store orphan commits, but if you have something you can't change in there or you catch it before you push, it will at least go away eventually.

Re: Fossil versus Git

#99

Post by mkl »

maccard wrote: post #76
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?

I'm not a fossil user but https://fossil-scm.org/home/help/purge

And yet:

> FURTHER WARNING: This command is a work-in-progress and may yet contain bugs.

Re: Fossil versus Git

#100

Post by masklinn »

dwpdwpdwpdwpdwp wrote: post #43
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…

Source control is all about managing diffs. Large files are fine, binary doesn’t make sense. Most of the time binary file diffs aren’t human readable. I store binary files outside of git but keep build logs containing binary file CRCs on git

> Source control is all about managing diffs. Large files are fine, binary doesn’t make sense

In git, diffs are literally just a UI thing.

Post reply on HN