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

101–110 of 252 posts

Re: Fossil vs Git

#101

Post by qznc »

ethomson wrote: post #48
Chyzwar wrote: post #37

Earlier quoted context omitted.

> It has nothing to do with the Windows filesystem; Git simply cannot support a 5 GB working tree on any filesystem. Can you provide a reference? I was searching a bit and only things I found was bugs in windows[1] for git lfs. > You can call this "pathological" but this throws a lot of shade on monorepos without much critical examination of how or when they might be useful. Windows codebase has 3.5 million files and…

> Can you provide a reference? I was searching a bit and only things I found was bugs in windows[1] for git lfs. Apologies, I hastily mistyped, I meant 500 GB , not 5 . (5 GB is about the size of my repository, which is not really so big at all and certainly something git can cope with on its own). This series of articles should illustrate some of the issues that VFS for Git tries to address. ("GVFS" is now called "V…

Plastic SCM claims that 5TB works and that 50GB is the average size in their cloud offering. It seems that the Free Software world does not care about such use cases.

https://medium.com/@psluaces/plasticscm-vs-git-c17934fad7ed

Re: Fossil vs Git

#102

Post by aboutruby »

SQLite wrote: post #79
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…

> When was the last time you visited git-scm.org?

Like most people, I go to Google which then redirects me to the correct Stack Overflow question/answer the most often. I think git-scm.org is mostly a guide to get started and the reference documentation.

Re: Fossil vs Git

#103

Post by Benjamin_Dobell »

endless1234 wrote: post #49
marktangotango wrote: post #44

Earlier quoted context omitted.

How often dou you actually look at this historic detail you seek to maintain? Daily, weekly, monthly? Is it more for to satisfy a feeling than an actual need? I mean if some junior dev wallows on some branch for 40 commits, I don’t want to see any of that, I just want to see what was finally merged.

I look at git blame (using 'Annotate' as IntelliJ calls it) quite often to figure out reasons for some certain change/implementation logic. It irks me when the result is just some giant squashed commit with 40 lines. Which of these explains this specific line? _History_ itself, yeah, not that much.

Would it not be significantly more frustrating if you use git blame and you see:

> Revert: Some WIP didn't work out.

Git blame again from prior to that commit.

> Added missing semicolon.

and again:

> Fixed spelling.

and again:

> Stupid typo, wrong method call.

and again:

> WIP, going to see if X can work.

Before running git blame once more, finally getting to the commit message that actually pertains to the current line of code you're seeing. Including the explanation (commit message) for why it is the way it is, and very importantly when this line of code actually made it into the software?

Re: Fossil vs Git

#104

Post by Terretta »

SQLite wrote: post #69

Additional links for the curious: https://fossil-scm.org/fossil/doc/trunk/www/quotes.wiki https://www.sqlite.org/whynotgit.html

I’ll pull what I consider an important quote into this thread:

> ”SQLite uses cathedral-style development. 95% of the code in SQLite comes from just three programmers, 64% from just the lead developer. And all SQLite developers know each other well and interact daily. Fossil is designed for this development model.”

FWIW, I consider this an extraordinarily productive development model.

Agile may be about People and Interactions over Processes and Tools, but (and it’s too often forgotten) all dev must first be about effective output in the problem space. So, how do you optimize ratio of Outcomes to People/Interactions/Processes/Tools? This model.

FWIW, I also consider Linus’ and Guido’s “BDFL” approach a way the bazaar is channeled back into a cathedral.

Re: Fossil vs Git

#105

Post by BeetleB »

SQLite wrote: post #72
donatj wrote: post #17

Earlier quoted context omitted.

> 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...

Other than the staging area, hg has all of these.

Re: Fossil vs Git

#106

Post by pmoriarty »

dan-robertson wrote: post #82
u801e wrote: post #73

Earlier quoted context omitted.

> 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.

If you tell hg to rename a file, e.g. hg mv foo bar, it will generate a patch which essentially just says “foo was renamed to bar”, and when you look at the diff the only thing that has changed is the name. If you merge this with a patch that changed foo then hg will do something sensible (ie either merge the changes into bar or give a merge conflict). Git has no first-class concept of file name changes. Instead it t…

"Git has no first-class concept of file name changes. Instead it tries to use heuristics to spot renames and sometimes they work and sometimes they won't."

Git has the "mv" command. If you "git mv" a file, why would git have to guess or use heuristics to figure out that the file was renamed?

Re: Fossil vs Git

#107

Post by kazinator »

pmoriarty wrote: post #106
dan-robertson wrote: post #82

Earlier quoted context omitted.

If you tell hg to rename a file, e.g. hg mv foo bar, it will generate a patch which essentially just says “foo was renamed to bar”, and when you look at the diff the only thing that has changed is the name. If you merge this with a patch that changed foo then hg will do something sensible (ie either merge the changes into bar or give a merge conflict). Git has no first-class concept of file name changes. Instead it t…

"Git has no first-class concept of file name changes. Instead it tries to use heuristics to spot renames and sometimes they work and sometimes they won't." Git has the "mv" command. If you "git mv" a file, why would git have to guess or use heuristics to figure out that the file was renamed?

Because git stores sets of files. If you move a file and make a new commit, it's just a new set of files which says "this old set is my parent". There is nothing in there about the renamed file.

Re: Fossil vs Git

#108

Post by dsego »

jordigh wrote: post #87
gugagore wrote: post #34

Earlier quoted context omitted.

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…

You misunderstand me. Almost everyone does. I do not think you should squash all of your changes into a giant hairball commit, and I don't think first parent (which is effectively the same thing) solves this problem either. I think each of your commits should be individually rewritten until each commit makes sense and tells a single, indivudal story that makes sense on its own, while at the same time be completely at…

There is a name for what you are describing, it's called "atomic commits". Every commit can stand alone and at every commit the software should be in a working condition.

Re: Fossil vs Git

#109

Post by pmoriarty »

kazinator wrote: post #107
pmoriarty wrote: post #106

Earlier quoted context omitted.

"Git has no first-class concept of file name changes. Instead it tries to use heuristics to spot renames and sometimes they work and sometimes they won't." Git has the "mv" command. If you "git mv" a file, why would git have to guess or use heuristics to figure out that the file was renamed?

Because git stores sets of files. If you move a file and make a new commit, it's just a new set of files which says "this old set is my parent". There is nothing in there about the renamed file.

Still, at the point you do a "git mv", it can't be said that git doesn't know you renamed a file. It knows.

In fact, after a "git mv foo bar", if you do a "git status", you'll see:

  On branch master
  Changes to be committed:
    (use "git reset HEAD ..." to unstage)
  
          renamed:    foo -> bar
If git chooses afterwards to discard that information and do nothing with that knowledge, that's a separate problem.

Re: Fossil vs Git

#110

Post by GuB-42 »

booleandilemma wrote: post #40

Your commit history should read like a published novel, not a first draft. I think I might’ve read something like that in the Pro Git book and it rings true with me. The philosophy of Fossil is to preserve the full history, which I think is a mistake.

Both approaches have value. And you'll find books advocating both ways.

Fossil takes a stance, git doesn't. It makes fossil less versatile but it is not a mistake. They never claimed Fossil to be the perfect solution for every project.

Post reply on HN