Live data from Hacker News

Fossil vs Git

fossil-scm.org

11–20 of 252 posts

Re: Fossil vs Git

#11
post #9

Funny how they say that Git uses a "Bazaar-style development" process when Bazaar literally is another VCS. I'm also not convinced it's a good idea to merge your bug tracker and version control.

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

Re: Fossil vs Git

#12
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 dread every time I have to use hg (and when I can use the git bindings for it). And I was using hg before I was using git.

git has a terrible UI, granted, but I find the hg UI pretty terrible too. I really hate their approach to branching (tho that is remedied these days with e.g. bookmarks to some extent).

Speaking of data model, I find gits model to be a lot saner. I REALLY hate that hg spams my disk with tons and tons of files within the .hg directory. Ever cloned e.g. the mozilla hg repos? ugh. Bonus points for their fancy name escaping mechanism in those files, which had me run into "path too long" issues on windows boxes a couple of times already.

Re: Fossil vs Git

#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?

Re: Fossil vs Git

#14
post #9

Funny how they say that Git uses a "Bazaar-style development" process when Bazaar literally is another VCS. I'm also not convinced it's a good idea to merge your bug tracker and version control.

There's a famous comparison of development styles that in turn predates the Bazaar software by years if not a decade.

Re: Fossil vs Git

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

To give a personal, subjective point of view of why I switched from hg to git: - hg was horribly slow compared to git; - I love the branchs model used in git to let several persons work on different parts of the same project, and I could never find a satisfactory equivalent using hg idiomatisms. It is true that hg has a far better UI in general, but Magit fixes this problem for me.

To add more praises about Magit: I would really love to use other DVCS, especially Fossil because it has built-in issue tracker and Wiki and all, but to be unable to use Magit with Fossil is a bigger drawback for me to make a switch.

At this point, I can basically do most of Git commands in Magit with just muscle memory; say, stage everything in the tree, commit amend, reset author and dates, then force push (I know) to remote I would just press with evil-magit: gsSc-Racp-fpy (gs for invoking Magit, S to stage everything, c to enter commit mode, -R set the reset author flag, a amend commit, p enter push mode, -f set the force flag, p push to origin, y confirm force push)

It may sounds complicated, but the Magit UI is discoverable, and once you're used to it you can do anything without even looking at the UI...

Re: Fossil vs Git

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

4) lots of foot guns

I would rather like a new option which was designed as a VCS from day one, that is user friendly and fast. Fossil is actually nearly there (I used it for a bit for some private projects)

Re: Fossil vs Git

#17
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 faster than Hg which made it the clear winner.

Re: Fossil vs Git

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

Git won over Mercurial simply due to Github. There were some other minor contributing factors - association with Linus, speed - but they are insignificant compared to how popular Gihub was (for good reason) and therefore how many people were exposed to git.

The Mercurial alternatives like bitbucket just didn't have the same spread, and we got stuck with year after year of teaching new people a difficult interface.

Re: Fossil vs Git

#19
post #8
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...)

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.

Re: Fossil vs Git

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

To give a personal, subjective point of view of why I switched from hg to git: - hg was horribly slow compared to git; - I love the branchs model used in git to let several persons work on different parts of the same project, and I could never find a satisfactory equivalent using hg idiomatisms. It is true that hg has a far better UI in general, but Magit fixes this problem for me.

The UI thing is more than superficial though. Yes, the command line is horribly inconsistent (and that can be fixed with Magit), but the real issue is that if you want to do anything non-trivial you have to understand how git works - what the object model is, how refs work etc.

I used mercurial successfully, quite heavily, and I couldn't tell you much about how it's implemented.

Post reply on HN