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

31–40 of 252 posts

Re: Fossil vs Git

#31

Post by byte1918 »

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?

In git you can do `git commit --amend --no-edit` to update your last commit, in case anyone is wondering.

Re: Fossil vs Git

#32

Post by jeltz »

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

The simple data model is the best part of git so I have no idea what you are referring to. I do not see how one could make it any simpler and still use it to implement a DVCS. The main reasons I picked Git over Mercurial were the data model and the performance.

Re: Fossil vs Git

#33

Post by fche »

The comparison lacks a big item: distributed-ness: the whole git-remote push & pull symmetry. It allows not only offline bare-minimum operation, but full offline development, then later online merging. I don't see any signs that fossil can do the same.

The comparison re. licenses is factually mistaken in several ways, but that's probably not worth a great deal of discussion - it's too religious a topic.

Re: Fossil vs Git

#34

Post by gugagore »

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

Groups should be able to be nested, of course.

The only way I know how to achieve this in git is my relying on no-fast-forward merges. There's a post detailing this approach [1], but unfortunately a lot of git tools don't support this workflow that well. I haven't gotten it to work well in gitlab, for example.

[1] Git First-Parent-- Have your messy history and eat it too : http://www.davidchudzicki.com/posts/first-parent/

Re: Fossil vs Git

#35

Post by tux1968 »

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.

Re: Fossil vs Git

#36

Post by jeltz »

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…

I guess the ability to use the bug tracker while offline is a nice advantage, but for that to be worth it it needs to be competitive with centralized bug trackers.

It is just like distributed code review tools, I wish there was any that was good enough but the ones that exist are too primitive to be worth the small gain of being able to seamlessly review code while on a flight.

Re: Fossil vs Git

#37

Post by Chyzwar »

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.

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

[1] https://github.com/git-lfs/git-lfs/issues/2434 [2] https://blogs.msdn.microsoft.com/bharry/2017/05/24/the-large...

Re: Fossil vs Git

#38

Post by kyrra »

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

Re 2: HG doesn't have a published data model. I believe they have created 2 or 3 models at this point so far, but I happens under the hood. They can do this as there is only 1 implementation of HG, so no need to worry about compatible as much.

Re: Fossil vs Git

#39

Post by dan-robertson »

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 revisions of a file as a list of blocks of “complete file” or “diff from previous version in this list”

Both have scaling problems to large repos and algorithm/data structure problems which cause too many operations to be e.g. O(size of history) at least. I suppose this is better than Darcs’ model of “commit on Friday and hopefully it will be done by Monday.” If hg we’re naturally good at scaling than e.g. Facebook wouldn’t be putting so much effort into trying to make it scale (e.g. using inotify instead of looking throughout the tree for changes (which I think shouldn’t count as any vcs gains from this), having a mergeless history, rewriting a ton of hg in rust (git was always partly in C and there is now also libgit2)).

The thing that makes me most sad about hg is the lack of a really good (ie good and emacs-based) ui.

I’m all for different vc systems being developed and I think it would be good to see some real innovation potentially break up the current git-hg hegemony.

I think there are lots of good things about fossil (e.g. using an actual database that is going to scale well and avoid data corruption instead of using a specialised data structure that is hard to change and likely not so corruption resistant or battle tested or scalable but maybe let’s your data structure be “faster” for certain operations)

Another interesting vc system being developed at the moment is pijul which can be simply described as “like darcs but fast and more likely to be correct”. It feels a bit like it’s fitting in with the current trend of CRDTs, although it’s core data structure is not a CRDT as that would imply that all merges have some deterministic resolution (ie merge conflicts do not happen) and that is not the case, instead files are allowed to be merged into a first-class conflicted state which can then be resolved by later patches.

Re: Fossil vs Git

#40

Post by booleandilemma »

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.

Post reply on HN