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

Fossil vs Git

fossil-scm.org

Post reply on HN
Print view View original

71–80 of 252 posts

Re: Fossil vs Git

#71

Post by dymk »

eesmith wrote: post #60
aboutruby wrote: post #47

Always surprises me how Fossil is popular on HN but very much not outside a few projects (e.g. sqlite)

How do you estimate Fossil's general popularity? Most projects are invisible to you, like in-house projects that never see the light of day. If Fossil is used by 1% of those projects, that's still a lot of projects. How can you tell if Fossil is popular in HN? By my reading, only two people in this thread use it. More than that mention having never heard of it before, or make statements where it's clear they don't re…

Fossil is posted to and discussed on HN all the time. It's a novelty, it differs in design from the popular tools that people actually use in their day-to-day jobs.

There's really no reason to think that Fossil is used internally at a rate higher than its public-facing usage. And I've literally never seen a project that uses Fossil aside from Fossil examples.

Re: Fossil vs Git

#72

Post by SQLite »

donatj wrote: post #17
fxfan wrote: post #2

I'm surprised git caught on despite mercurial being much superior (hadn't heard of fossil before). Git has the following shortcomings which are major (some shared by other VCS too) 1) UI- terrible, terrible UI 2) Unncessarily complex data model 3) Doesn't scale well to large repos (until Microsoft's VFS- windows only) (and many others...)

> 2) Unncessarily complex data model Hmm? It’s just a directed graph of SHA1s under the hood. Seems pretty simple to me once you understand that. My understanding was that Hg’s data model is actually way more complicated with more pointers. As everyone else is chiming in, the reason git won was speed. I haven’t used mercurial in a few years but at the time when I was looking to replace SVN, git did everything seconds…

Perhaps the OP is referring to this: https://www.sqlite.org/whynotgit.html#the_mental_model_for_g...

Re: Fossil vs Git

#73

Post by u801e »

dan-robertson wrote: post #39
fxfan wrote: post #2

I'm surprised git caught on despite mercurial being much superior (hadn't heard of fossil before). Git has the following shortcomings which are major (some shared by other VCS too) 1) UI- terrible, terrible UI 2) Unncessarily complex data model 3) Doesn't scale well to large repos (until Microsoft's VFS- windows only) (and many others...)

I think git and hg are both pretty bad in different ways. Both have pretty terrible UI but so long as one uses magit, git comes out way on top. The data models are different and suffer different problems. A main issue with git is that it is stupid about file copies and renames. An issue with hg is that it doesn’t work well with long running forked histories (i.e. like git branches) because it stores the set of revisi…

> A main issue with git is that it is stupid about file copies and renames.

Could you elaborate on this? As far as I know, file copies and renames will still use the same blob, but the tree referencing the blob can reference it using a different path in the case of a rename or reference it more than once in the case of a copy.

Re: Fossil vs Git

#74

Post by emerongi »

tux1968 wrote: post #35

One of the bullet point advantages listed for Fossil of allowing multiple checkouts per repository is also supported by Git. There has always been a way to do it, but since Git 2.5 or so, the "worktree" sub command was added for this purpose.

Huh. I've just used another git clone of the repo, but the worktree command seems to fit my uses very well. Thanks.

Re: Fossil vs Git

#76

Post by kurtisc »

git-worktree seems to give git the multiple-checkouts feature.

Also, this page seems to do the common but frustrating thing of advertising how something is implemented as a feature. I'm sure it's very interesting to the developers that it uses a database in the backend or that your side-project is written in a niche language but, as an end user, I just don't care.

Re: Fossil vs Git

#77

Post by FPGAhacker »

jordigh wrote: post #13

I'm a big, huge fan of recording what should have happened instead of recording every typo and forgotten semicolon in your history. There's a difference between draft commits and published commits. When I'm reading published commits, i.e. history, I just want to know your intent, not your typos. So what are the tools that Fossil offers to make sure I don't have to see your typos in the history?

I don’t squash commits very often, but I do re-order them. When i have a pile of changes to commit that aren’t always perfectly related, I will sometimes check in the cart before the horse. Rebase lets me correct that order.

So perhaps fossil really “shows what actually happened” but perhaps the more accurate statement is it shows the actual commit order. And that may not reflect the actual order of what was done, leading to an inversion of the logical progression of the code.

That said, I’m going to try it anyway for the ticket system and wiki. I use a two tier vcs system. “Official” work goes into svn and I have no control over that. Interim work for me is in git. But I’d like tickets and wiki docs to help me track issues that I can’t get to right away and sometimes forget about after a month or two.

Re: Fossil vs Git

#78

Post by Nullabillity »

nobody271 wrote: post #64
Benjamin_Dobell wrote: post #59

Earlier quoted context omitted.

Are you pushing the commits with errors? Are you merging the commits with errors? If both of those are true then this sounds like a process issue. Git makes it extremely easy to edit history, with the ability to amend any commit; even several commits back with simple CLI tools like `git rebase -i `. However , what it doesn't like you doing is ripping the rug out from other people i.e. editing history team members are…

Hmm, okay, I should learn how to rebase then. The biggest part of my problem is a total lack of commit discipline but there are times when I'm working on a branch where my commits don't tell a clear story (changed something then changed it back because I decided to do it a different way). That's when I most wish for better ways to tell that story. I feel like an idiot for not knowing rebase could solve some of this f…

That back and forth is the most important part of the story! It shows that you thought through multiple approaches to the problem, (hopefully) why they didn't pan out, and they give someone else a starting point for returning to that approach in the future.

It isn't exactly rare that I go through the blame history on some project to find out why something was done in a way that seems stupid at first glance, just to get stuck on a giant squash commit saying "Implemented X".

Re: Fossil vs Git

#79

Post by SQLite »

aboutruby wrote: post #47

Always surprises me how Fossil is popular on HN but very much not outside a few projects (e.g. sqlite)

Some data:

The fossil-scm.org server gets between 1500 and 2000 distinct human visitors per day on weekdays. (Lower traffic on weekends. Robots are excluded from the count. "distinct" means visitors having different IP addresses.) This is perhaps orders of magnitude less than git-scm.org (I'm guessing - anybody have stats?) but it is also non-trivial. With ~1750 visitors per day somebody must be using it. And I would guess that most actual users do not visit the site daily. (When was the last time you visited git-scm.org?)

FWIW, today has already seen in excess of 10,000 distinct human IPs, likely due to this HN post.

Re: Fossil vs Git

#80

Post by bluejekyll »

gugagore wrote: post #34
jordigh wrote: post #13

I'm a big, huge fan of recording what should have happened instead of recording every typo and forgotten semicolon in your history. There's a difference between draft commits and published commits. When I'm reading published commits, i.e. history, I just want to know your intent, not your typos. So what are the tools that Fossil offers to make sure I don't have to see your typos in the history?

I'm also a big fan of not deleting data. I don't like squashing commits, for example. But I also want to be able to see high-level intent. If instead of "squashing", it were "grouping", I'd be happy. I could encapsulate a bunch of messy commits that I made while I didn't know what I was trying to do. The intent would be clear at a higher level, but if you want to dig in to see what it actually took me to achieve that…

I sometimes go back and “group” commits with a ‘git rebase -i’ and squash commits that are related.

Is that similar to what you’re talking about?

Post reply on HN