Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fossil Versus Git

fossil-scm.org

Post reply on HN
Print view View original

31–40 of 89 posts

Re: Fossil Versus Git

#31

Post by avar »

jwecker wrote: post #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 exci…

    It's not as if rebase is commonly used.
This is widly incorrect. Powerusers of Git use rebase extensively, pretty much every patch that makes it into Git itself has been rebased at least half a dozen times.

I rewrite my history constantly, because when writing code I commit all the time, then I squash commits together later and give them proper commit messages.

I wouldn't use any SCM tool that wouldn't give me this functionality. The result of recording all history permanently is that users will just not commit their incomplete work, meaning that it'll be in their working tree instead of tracked in some form by the repository.

Re: Fossil Versus Git

#32

Post by stonemetal »

iloveponies wrote: post #23
cpenner461 wrote: post #16

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

I can see calling the wiki, and blog part of it bloat but bug tracking seems like a good thing to keep with the repo. If you are some where without network access, and you commit a bug fix you can update the bug tracker right then and there. No chance of forgetting to do it latter.

Re: Fossil Versus Git

#33

Post by prodigal_erik »

etherealG wrote: post #30
gecko wrote: post #14

Earlier quoted context omitted.

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.

Git has many commands which allow fine-grained manipulation of the staging area; stashes are a crude afterthought in comparison. The problem is that highly encouraged workflows like "git add --patch" inevitably lead to toxic commits which were never tested because they never truly existed in the workspace.

Re: Fossil Versus Git

#34

Post by andos »

philwelch wrote: post #11

"Git provides file versioning services only, whereas Fossil adds an integrated wiki, ticketing & bug tracking, embedded documentation, and News/Blog features. These additional capabilities are available for Git as 3rd-party user-installed add-ons, but with Fossil they are integrated into the design." Am I the only one who's actively suspicious about this kind of thing? With Git, I can use whatever wiki, ticketing, do…

Have you ever tried to set up a Gitorious box?

Not that it's difficult (it is) but it is a complete waste of people's time. If I want to fiddle with every aspect of my development tools, maybe I'm not Fossil's target.

Next time I need to set a small coding project (I attend a few OSS hackfests every year), I'll definitely consider Fossil instead of git.

Re: Fossil Versus Git

#35

Post by stonemetal »

wccrawford wrote: post #4
andrewvc wrote: post #2

Look, 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."

Agreed. Having a small community and not being well-known are not advantages. They try to say that your voice will be comparatively louder and you'll get more attention from the developers, but in a large community, you get attention from the community as well. The only thing you can get from using an unpopular project is an adrenaline rush from living on the edge.

Having a small community and not being well-known are not advantages. I am not sure I can agree with this. Smaller communities are often nicer. Think of all the talk around here of growing pains, loss of niceness, comparisons to Reddit or Dig, eternal September, etc. that have come about as the community grows.

Re: Fossil Versus Git

#36

Post by DamagedProperty »

philwelch wrote: post #11

"Git provides file versioning services only, whereas Fossil adds an integrated wiki, ticketing & bug tracking, embedded documentation, and News/Blog features. These additional capabilities are available for Git as 3rd-party user-installed add-ons, but with Fossil they are integrated into the design." Am I the only one who's actively suspicious about this kind of thing? With Git, I can use whatever wiki, ticketing, do…

Also to add that Git doesn't track files it tracks content.

Re: Fossil Versus Git

#37

Post by mnutt »

zem wrote: post #12
philwelch wrote: post #11

"Git provides file versioning services only, whereas Fossil adds an integrated wiki, ticketing & bug tracking, embedded documentation, and News/Blog features. These additional capabilities are available for Git as 3rd-party user-installed add-ons, but with Fossil they are integrated into the design." Am I the only one who's actively suspicious about this kind of thing? With Git, I can use whatever wiki, ticketing, do…

"github in a box" is a superb tagline, though. that was my favourite bit in that article.

Given a pile of cash, you can actually buy "github in a box":

http://fi.github.com/

I believe it's JRuby-based.

Re: Fossil Versus Git

#38

Post by StavrosK »

gecko wrote: post #15
wladimir wrote: post #7

Earlier quoted context omitted.

Oh no, not another SCM. My head is already bursting from learning Hg and Git... Also I don't think "lack of rebase" is a feature. If you don't want it in git, just forbid using it for your project. However, if you want to maintain a patch-set outside of a project it's the best thing since sliced bread.

Fossil's solution to that are private branches and stashes. That said, I'm with you in preferring rebasing for this kind of thing. (And I'm not even a Git user; I'm pretty wedded to Mercurial.)

I used to use bzr, then I used git and was blown away by the speed. I switched to it, still learning the (very hairy) commands, but really enjoying the speed.

One day, I tried hg by chance and discovered it was as fast as git and as sensible as bar :( Now I have no idea what to use.

Re: Fossil Versus Git

#39

Post by Scaevolus »

avar wrote: post #31
jwecker wrote: post #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 exci…

It's not as if rebase is commonly used. This is widly incorrect. Powerusers of Git use rebase extensively , pretty much every patch that makes it into Git itself has been rebased at least half a dozen times. I rewrite my history constantly, because when writing code I commit all the time, then I squash commits together later and give them proper commit messages. I wouldn't use any SCM tool that wouldn't give me this…

Agreed, without rebasing the history for projects with lots of developers quickly becomes a mess.

> Fossil deliberately avoids rewriting history. Fossil strives to follow the accountants philosophy of never erasing anything. Mistakes are fixed by entering a correction, with an explanation of why the correction is needed. This can make the history of a project messy, but it also makes it more honest.

I'm not sure how keeping garbage like "oops, fix typo" out of history is lying to your fellow developers-- a VCS should be aiding development, not forcing others to see your little mistakes.

Re: Fossil Versus Git

#40

Post by shasta »

Scaevolus wrote: post #39
avar wrote: post #31

Earlier quoted context omitted.

It's not as if rebase is commonly used. This is widly incorrect. Powerusers of Git use rebase extensively , pretty much every patch that makes it into Git itself has been rebased at least half a dozen times. I rewrite my history constantly, because when writing code I commit all the time, then I squash commits together later and give them proper commit messages. I wouldn't use any SCM tool that wouldn't give me this…

Agreed, without rebasing the history for projects with lots of developers quickly becomes a mess. > Fossil deliberately avoids rewriting history. Fossil strives to follow the accountants philosophy of never erasing anything. Mistakes are fixed by entering a correction, with an explanation of why the correction is needed. This can make the history of a project messy, but it also makes it more honest. I'm not sure how…

It's not just "oops, typo", but also "oops, someone checked in something proprietary." Being able to scrub the version history before you publish it is more or less is almost a requirement in certain environments.
Post reply on HN