This does not make me interested in Fossil.
Fossil Versus Git
21–30 of 89 posts
Re: Fossil Versus Git
#22Earlier quoted context omitted.
I logged in to make the same comment. If you want someone to use your product, the best way to do that isn't to call them sheep
I agree... I think that making the argument "try fossil because no one else uses it" is just as bad as recommending using git because everyone does. Why not judge it on it's merits?
Wide usage is a merit.
If you know git you can contribute to any project on github more easily. That is an advantage, though it would be utterly foolish to make your choice solely on this point.
Re: Fossil Versus Git
#23The fact that fossil has "Versioning, Tickets, Wiki, and Blog/News", really puts me off this, actually. I'm not massive into the unix philsophy, but this seems like bloated: they should be separate things, even if they're interconnected imo.
This is from the author of SQLite, which I would say is pretty bloat free, so I would think that he has applied the same development style to Fossil. I've stayed away from fossil as an SCM because it doesn't have the traction that others do (I personally prefer mercurial), but I have used it a few times where I needed a wiki and bug tracker, setup is about as simple as you can get.
The bloat in this case is not necessarily dependencies or size of code base. It's features, and compared to other VCS's that don't have a wiki, bug tracking, an entire web server etc on board by default.
Re: Fossil Versus Git
#24Look, new projects should have these pages, and they SHOULD be passionate and biased. However, shit like this makes me stop reading: "Git has a huge user community. If following the herd and being like everybody else is important to you, then you should choose Git."
"following the herd"? Yeah, git's had a lot of adoption (methinks primarily due to github), but I work with loads of people who are just getting up to speed with subversion. VCS of any type gives them a headache - "distributed" is even worse. Some client's I worked with in 2010 had no version control at all. "Following the herd" seems a little myopic. :)
Re: Fossil Versus Git
#25Earlier quoted context omitted.
This is from the author of SQLite, which I would say is pretty bloat free, so I would think that he has applied the same development style to Fossil. I've stayed away from fossil as an SCM because it doesn't have the traction that others do (I personally prefer mercurial), but I have used it a few times where I needed a wiki and bug tracker, setup is about as simple as you can get.
The bloat in this case is not necessarily dependencies or size of code base. It's features, and compared to other VCS's that don't have a wiki, bug tracking, an entire web server etc on board by default.
The value of having tickets directly (which are fossil artifacts) be able to reference/link-to other artifacts (checkins, events, other tickets) is something that maybe needs to be tried to be fully appreciated. When repos are clones, all that info travels w/ the repository, so there's never a broken record of what's happened. The webserver is also really handy for interfacing the repo. It serves it's purpose well, and I personally wouldn't wish it away. Whether it's something as simple as an ad-hoc "fossil ui" to run the server and load a view into firefox for a quick glimpse at the timeline, or running it fulltime so a dev. team can get a better clue of their branching/merging, it's a nice feature.
Re: Fossil Versus Git
#26... or just go install your own gitorius, and continue benefiting from all the tooling support you already enjoy.
Re: Fossil Versus Git
#27"The lack of a 'rebase' function is considered a feature of Fossil, not a bug."
It's not as if rebase is commonly used. It's there for those rare instances when you, say, remove a file that it turns out you don't have the copyright for and need to purge it completely, or that huge binary file some newb (ok, it was me) committed a while back that's not needed and makes cloning take 10 minutes.
Fossil looks really exciting to me- I've used git a ton and like it but don't really delude myself into thinking it can't be disrupted. But, seriously, you're missing a critical feature; instead of trying to patronize your would-be future users by defensively stating that it's a "good thing and we're proud of this missing functionality"- you could simply state something along the lines of "In general we think not having the equivalent of rebase is a good thing, but should you seriously need something like it, this is opensource and we'd love for you to contribute..." etc.
[Edit: I'm referring to git-filter-branch etc. to remove those things, not the rebase command per se, but in context of the original page's "Immutable==good" argument I interchanged the two]
Re: Fossil Versus Git
#28IMO the "Sharding versus Replicating" section sounds a little bit like someone is trying to sell me on a centralized VCS after I've already switched to and enjoy DVCS. And further down in the same section, it sounds like the author has confused Git itself, with the way Git is used developing the Linux kernel. Just because the Linux kernel devs use Git in a particular way doesn't mean Git encourages any one particular…
WRT selling you on centralized VCS after you've switched to and enjoy DVCS:
That was my immediate reaction, but I realized that there is a third thing. In a way, a git-like DVCS in most workflows still retains some of its 'centralized' state - that is, some repositories are the only repositories with certain branches etc. and often there is a specific repository on a server that has all branches "that matter" (such as a github account). As mentioned, Kernel developers need this to reduce clutter/noise and establish arbitrary hierarchies (that are, in a sense, centralized).
This "third thing" is, in a way, even more decentralized than old-school CVS/SVN- in that all repositories truly become equal. I'm not saying it's better than git-style-DVCS- it's certainly not if you need an ad-hoc high branch-volume hierarchy- but I do think that it's an underdeveloped use-case that's neither centralized nor adhoc distributed that might (maybe not as Fossil per se) be very useful to many workflows.
Put another way- how often do git workflows have you push/pull from multiple remotes when you're ready to deploy (or at all)? In the vast majority of workflows that I've seen and used you generally have one authoritative remote. Something like Fossil would make it so that a push/pull to any remote is effectively the same thing.
Re: Fossil Versus Git
#29Github to git, is like Tarpit to fossil :)
Too bad tarpit.com is taken :(
Re: Fossil Versus Git
#30Does anyone know whether fossil has a staging area? I tried but could not find it. Google didn't really help either.
Fossil does not have a staging area. Instead, like Mercurial, it encourages you to stash things you do not plan to commit.
if you stash everything you're not committing, then the working copy becomes the staging area, and the stash becomes the working copy. how is that any different?
seems to me both systems have a method of choosing what to commit, in git you can choose to stash or stage, in the others you can only stash since they "don't have a staging area". git++ for having both options.