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

41–50 of 252 posts

Re: Fossil vs Git

#41

Post by Vinnl »

messe wrote: post #29
Vinnl wrote: post #22

> Fossil, in contrast, puts more emphasis on recording exactly what happened, including all of the messy errors, dead-ends, experimental branches, and so forth. I think this is an interesting distinction. The question is: what is the function of the history? Is it to document what happened - and if so, shouldn't every keystroke be committed? Or is it to document which changes relate together, and e.g. should be rever…

> One thing that isn't mentioned is whether Fossil supports working offline as well as Git does. My impression from this page is that it emphasising creating every branch on a server as well, which implies you need to be connected? If so, I'd consider that a "missing feature" as well, as it's something I use regularly enough and that's important enough that it'd be something I'd miss if it weren't there. The way foss…

Thanks, that makes sense then.

Re: Fossil vs Git

#42

Post by mannykannot »

Vinnl wrote: post #22

> Fossil, in contrast, puts more emphasis on recording exactly what happened, including all of the messy errors, dead-ends, experimental branches, and so forth. I think this is an interesting distinction. The question is: what is the function of the history? Is it to document what happened - and if so, shouldn't every keystroke be committed? Or is it to document which changes relate together, and e.g. should be rever…

One should not have to choose - the history of complete units of work should be an abstract view of the detailed history.

Re: Fossil vs Git

#43

Post by SSLy »

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…

>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 can see all my experimentation by looking at the commits inside the group.

That oddly sounds like a feature available in mercurial.

Re: Fossil vs Git

#44

Post by marktangotango »

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…

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.

Re: Fossil vs Git

#45

Post by fxfan »

Frondo wrote: post #24
fxfan wrote: post #11

Earlier quoted context omitted.

Have you actually tried their model of bug tracking and code revision integrated?

I have, and the built-in tools are weak or cumbersome to the point of being useless (or were when I moved off to bitbucket). The wiki had its own weird markup at the time, so people who might have helped me write documentation were faced with learning a weird new markup (they were volunteers, that's a tough ask.) The bug tracker had no way to send emails, and you were expected to rig up some external systems to do th…

The parent I replied to had an issue with the (assumed) model. You have an issue with features. All your points are valid- the parent had no points to debate validity of.

Re: Fossil vs Git

#46

Post by fxfan »

ethomson wrote: post #19
Chyzwar wrote: post #8

Earlier quoted context omitted.

1) It is not beginners friendly but for day to day dev you only need to understand few commands. 2) Data model brings speed that was not possible before. git won VCS space because of sheer performance. 3) Scale just fine. Just windows have a really bad filesystem and Windows codebase is the pathologic case.

It has nothing to do with the Windows filesystem; Git simply cannot support a 5 GB working tree on any filesystem. 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.

Git lacking a functionality has nothing to do with monorepos not being useful.

Re: Fossil vs Git

#48

Post by ethomson »

Chyzwar wrote: post #37
ethomson wrote: post #19

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

> 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 "VFS for Git".)

https://docs.microsoft.com/en-us/azure/devops/learn/git/tech...

And this is a series of articles from an engineer who's been working on improving perf in large repositories in general, not strictly related to the Windows repository:

https://blogs.msdn.microsoft.com/devops/2018/06/25/superchar...

> Windows codebase has 3.5 million files and its repo is 300GB in size. It is not normal. This is google or MS type of problem and not average git user. MS instead changing workflow decided to create GVFS[2]

I didn't say it was normal. Indeed it's uncommon. I said it wasn't pathological.

Re: Fossil vs Git

#49

Post by endless1234 »

marktangotango wrote: post #44
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…

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.

Re: Fossil vs Git

#50

Post by bensummers »

I choose fossil at a time when it wasn't clear which one of fossil, Mercurial, or git would "win".

I choose it because it had a very clear and easy UI, guided you towards a way of working that is suitable for small teams (ie 99.99% of all projects), and had an approach to history which made it unlikely you'd ever accidentally lose work.

The only thing which has ever made me sad about my choice is pressure from people who think everyone should use git.

It also has some very nice features, like being able to give you a full web UI just by running it as a CGI process on a web server.

It is worth trying (and it can import and export git history). Just remember it's not git.

Post reply on HN