
Fossil Versus Git - dfox
http://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki
======
jrockway
_Git features the "rebase" command which can be used to change the sequence of
check-ins in the repository. Rebase can be used to "clean up" a complex
sequence of check-ins to make their intent easier for others to understand.
From another point of view, rebase can be used to "rewrite history" - to do
what Winston Smith did for a living in Orwell's novel 1984._

This is FUD. Git never erases history; it merely moves mutable _refs_ around.
When you rebase a branch called "master", nothing is rewritten: a new
immutable commit history is created, and the ref "master" is moved from
pointing at the old history to pointing at the new history. The old history
still exists in all its glory at "master@{0}". (And when you change that, it
goes to master@{1}, and so on.)

If git didn't have the concept of refs, then this would never even worry
anyone. Once you have commit ab387df, it's refers to the same sequence of
changes for all eternity. What master points to may change out from under you,
but the history never goes anywhere.

The only way to "rewrite history" is to delete every copy of the repository
ever made, which is exactly how you would rewrite history with Fossil or
Subversion or anything.

(And now, if I may, a digression. I've noticed that the "rewriting history"
aspect of Git makes for a good personality test. It's strongly polarizing --
the people that think source control is designed to be documentation love it,
and the people that think source control is an audit mechanism hate it.
Control freaks hate git, and long-haired hippies seem to love it.)

~~~
billjings
I'm not familiar with other DCVS tools, but I have delved pretty heavily into
the history rewriting capabilities of git. Git is just a power tool. It won't
ruin your day like rm -rf will, but it will give you enough rope to rappel
your way down into ontological horror.

I have been using it to write extended tutorials on my local system. I may
find a bug at step 45 that needs to be fixed back at step 2. I am pretty sure
that git was never designed for me to do this, but it can be done pretty
safely, in a way that I can recover from.

Now, is this method of going back and fixing things in the past a good idea
for general software development? Absolutely not! If I wrote a bug in march,
it serves the team rather poorly to go back and replace every commit in the
master branch with a new one that doesn't have the bug. And that's why I feel
it's accurate to call it rewriting - sure, git keeps enough data around for
you to recover from any boneheaded edit you may make to a branch, but from the
perspective of a teammate you're still going back and modifying history. It's
still confusing. You're still creating new commits out of their commits that
have the same name, but different contents.

~~~
pyre
You're not looking at the possibility that someone may do a bunch of
development locally, then use rebase to clean it (the local changes) up before
pushing it out to a central repository (or merging it into master). If you're
really paranoid that someone will use rebase to screw up master, you can use a
tool like gitosis or gitolite to manage permissions on a central repository.
You can say that no one has permissions to push things to master that are not
fast-forwards.

Scenario #1:

    
    
      I'm working on a feature branch. I have a number of discrete changes
      that I'm making. I attempt to keep each of these changes in its own
      separate commit. After completing 10 such changes, I realize that I
      introduced a bug in change 3. I commit the bugfix with the same
      commit message title as change 3, but with a "squash!" prefixed at
      the front of it. Now when I'm finished with my changes on the
      feature branch I can run "git rebase -i". git-rebase will
      automatically position the bugfix to change 3 next to change 3 and
      set it up to be squashed into the change 3 commit. Then when I merge
      my changes into master there are only commits for changes 1-12,
      instead of 50 commits covering all of the minor bugs that I fixed
      with my undeployed code.
    

Scenario #2:

    
    
      Rewriting commit messages. This is one that I use all of the time at
      work. I use a commit message template that has "Reviewed-by: ???" at
      the bottom. When I do all of be topic branch development, I don't
      get someone to review each individual commit prior to commiting it
      (as that would defeat the purpose of a DVCS... might as well go back
      to SVN at that point and managing chunks of changes prior to commits
      with something like `quilt`). So now all of my commit messages have
      "Reviewed-by: ???" on them. Prior to merging the changes back into
      master, I can use git-rebase or git-filter-branch to go back and
      edit my history to change "Reviewed-by: ???" to "Reviewed-by: Bob"
      on my commit messages.

~~~
GrandMasterBirt
Often when pairing we'd commit with messages like "WIP: 1" "WIP: 2" etc. push
pull switch machines (remote pairing) get checkpoints in there. Then before
pushing to the main branch we'd roll all that up into one commit with a very
helpful message. Boom solves a great workflow problem.

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

~~~
chc
It also backs this point up with yet another abuse of the most misquoted poem
ever, Robert Frost's "The Road Not Taken."

The poem isn't actually in praise of making unusual choices — it's about
rationalizing the choices we make so that they seem more intelligent and
important than they actually were. In the text of the poem, the narrator goes
to great lengths to make it clear that he can't tell any difference between
the paths in front of him. So he decides to choose one arbitrarily, and tells
us that years from now, he'll _tell people_ that he took this little-traveled
road and that set the course of his life.

~~~
gjm11
He kinda contradicts himself. "Then took the other, as just as fair, / And
having perhaps the better claim, / Because it was grassy and wanted wear;"
seems to imply that the one he took was indeed "less traveled"; but then,
immediately, "Though as for that the passing there / Had worn them really
about the same,". It doesn't seem to me that there's any Right Answer to the
question: Are we supposed to understand that the path he took really was less-
travelled, or not?

My reading of the last stanza differs from yours: he's not saying that he'll
tell people, falsely, that it set the course of his life; he's saying that
although he couldn't see any good reason for choosing one over the other, as
his life goes on it'll turn out that it made a big difference.

The thing that intrigues me about this poem (which, actually, I don't much
care for despite its fame) is the title. "The road not taken". That's not the
perhaps-less-worn path he _did_ take, it's the other one. Without that title,
if you asked me which path was more the subject of the poem I'd have said
without hesitation: the one he took, which "has made all the difference". But
no: the spotlight is on that sigh with which Frost will be telling the story,
the regret (if that's the right word) that he couldn't try them both. I think.

~~~
palish

      TWO roads diverged in a yellow wood, ...
    
      [Road "First", aka "Scary Road"]
      And looked down one ... To where it bent in the undergrowth; ...
    
      [Road "Other", aka "Happy Road"]
      Then took the Other, as just as fair,
      And having perhaps the better claim, ...
    
      Oh, I kept the First for another day!
    

In other words, "I didn't take the First road; I took the Other road."

Substituting, this brings us to, "I didn't take the Scary Road; I took the
Happy Road."

Then, the key is...

    
    
      Though as for that the passing there	
      Had worn them really about the same, ...
    

This means "both roads were equally traveled". So therefore we must
extrapolate into the future. Take a thousand average people. Not
entrepreneurs; think more along the lines of Grandma. Now show them a Scary
road and a Happy road, then ask them to choose. Which one are they more likely
to select?

I'd say the Scary road is the one "less traveled".

    
    
      I shall be telling this with a sigh, ...
    

Why would he sigh if he were not lying?

    
    
      Two roads diverged in a wood, and I—	
      I took the one less traveled by
    

This means he claimed to have taken the "less traveled" road, which is the
Scary road. But he took the Happy road.

Therefore, the poem is about a lie.

~~~
jodrellblank
Why would the first road be "scary" and then the other be "just as fair"?
"Fair" is a positive description.

If both roads are just as fair as each other, there isn't one scary one and
one happy one, there's either two scary ones or (more likely) two happy ones.

Anyway, shouldn't it be ONE road diverged in a yellow wood? If TWO roads
diverged, that would make four.

The poem is about a man who, "years and years hence", will be remembering his
life, and up there near the top of his memories to tell people about is how he
chose which of two almost identical paths he took when walking in a wood,
once, and they were roughly the same. Does that sound like the sort of memory
someone who would pick a scary road would choose to reminisce about? Does it
sound like the sort of tale a habitual liar would tell? No to both. It sounds
like the sort of tale a really boring person with no interesting memories
would tell.

He was walking through a wood, not trying to get anywhere in particular and
not caring where he went. It was probably quite pleasant, and it wasn't the
hundred acre wood or the Lord of the Rings evil forest, both roads came out
the other side of the wood and then he went home.

------
js2
Fossil is a great little SCM, written by the author of SQLite. This is
probably the most controversial page on the fossil-scm.org site. It is
intended, I think, to be provocative - don't take the bait. :)

Instead, explore the other documentation on the site and see whether it's an
SCM for you.

Zed Shaw wrote a perfectly reasonable post about why he uses it:

<http://sheddingbikes.com/posts/1276624594.html>

Discussion: <http://news.ycombinator.com/item?id=1433387>

Also <http://news.ycombinator.com/item?id=809493>

~~~
jodrellblank
When did Zed Shaw write that? I can't see a date tag on the entry; He uses
Fossil "these days", is that 2011 or 2006?

~~~
askedrelic
Looks like the blog url is a timestamp, 1276624594.

    
    
      ruin:~$ date -r 1276624594
      Tue Jun 15 13:56:34 EDT 2010

------
philwelch
"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, documentation, and blog features I
want. I don't want my VCS to be a Lotus Notes for software development.

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

~~~
philwelch
_Have you ever tried to set up a Gitorious box?_

No, I just use GitHub. Is there a hosted Fossil service that's as easy to use?

~~~
andos
When the project allows me to go hosted, then the problem is already solved.
Thrice. When it does not, but I still need versioning, a wiki and some issue
tracking and I don't feel like sporting my masochist hat, good news for me:
there's now a tool that does it all and it's a single binary that needs no
setting up.

And I don't know if there's any hosted Fossil service around, easy to use or
otherwise.

------
click170
IMO 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 model over another.

Does anyone know of a more technically accurate and less biased comparison?

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

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

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

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

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

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

~~~
avar

        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.

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

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

~~~
bch
This is actually solved in fossil via "shun". The case of publishing a
password or credit card numbers or $seriousMistake will be attributed to an
artifact. Applying "shun" to that artifact will prevent it from being pushed
to remote repos, and, on repo rebuild (a local operation), that artifact will
be completely removed from the repository (locally). The list of shunned
artifacts is maintained forever however, so if the artifact is re-introduced
via a pull from some other repo, the shun that was previously applied will
still be in effect, and keep the artifact from being further propagated by
this repo.

~~~
zbanks
So fossil _does_ have rebase?

~~~
bch
I'm not a git expert, but iiuc, git rebase is a way to re-present a subtree as
a single checkin, or otherwise re-work the commit tree to clean it up. It's
also a big part of git culture.

In fossil, there _is_ such a thing as a private branch that will not be
pushed/pulled when repos sync w/ ea. other, but the owner of that private
branch can ultimately merge the work, and it will appear as a single atomic
commit (ie: a single checkin, not all the multiple artifacts describing the
whole of the work in the private branch). I'd think that's the closest thing
to rebase that fossil has. Even in that case, though, there's no explicit
moving of artifacts; when the work is merged to a public branch though, all
the work appears as the condensed net change, in a single checkin.

Otherwise, culturally speaking, re-working of the tree is -not- the way the
repository is handled. Errors are fixed w/ corrective checkins, and both will
show in the history.

jrockway sheds some light on git rebasing here
(<http://news.ycombinator.com/item?id=2524993>) though, which I'll look into
myself to come to understand. Before, I thought rebase was more 'destructive'
than what that description indicates.

------
cageface
Fossil would have to be _much_ better than Git for me to take a serious look.
I'm not interested in micro-optimizing every single piece of my toolkit. Git
is the DVCS with all the momentum and mindshare and it does what I need it to
do. I have bigger fish to fry.

------
ognyankulev
Some NetBSD are considering moving to Fossil. It's notable that Fossil's
license is BSD while Git and Mercurial are GPLed. Some interesting pages pop
up while search "NetBSD Fossil", like <http://www.sonnenberger.org/> or
interesting quote from Fossil's author in [http://mail-index.netbsd.org/tech-
repository/2010/01/18/msg0...](http://mail-index.netbsd.org/tech-
repository/2010/01/18/msg000350.html) :

"I suppose my biggest concern with Fossil and NetBSD is how Fossil might
scale. We use Fossil on projects with a 1GB or larger check-out and with
thousands and thousands of files. But I didn't really design fossil for truly
huge projects."

------
Griever
I'm all for competition, but how do they come across saying that Git is
complex while Fossil is intuitive? Is it possible to still be intuitive while
still being a "complex" system? I'm not exactly a Git master, but I have had
absolutely no troubles using it after getting everything setup.

------
teh
Does anyone know whether fossil has a staging area? I tried but could not find
it. Google didn't really help either.

~~~
gecko
Fossil does not have a staging area. Instead, like Mercurial, it encourages
you to stash things you do not plan to commit.

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

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

~~~
hammerdr
Commits aren't dangerous until you push them. You can very easily rebase out a
committed patch after you've tested it.

~~~
etherealG
with great power comes great responsibility :)

------
pyninja
This does not make me interested in Fossil.

~~~
swaits
That's too bad. Though I mostly use mercurial, when it's appropriate and I get
to choose, I've played with fossil and it is quite a nice package. Super easy
to setup, fully featured, easy to use, and does what I want. Before you
shitcan the whole idea, why not play with it for a few minutes?

~~~
nimrody
It would help if at least Fossil could use a Git repository (similar to the
git plugin for Mercurial).

No point in having different projects using multiple version control systems.

~~~
__david__
There is when they have significantly different properties/workflows. I happen
to think Darcs is supremely good for web development (probably not at facebook
scale though)--it's the triviality with which you can cherry-pick patches that
makes it wonderful to fast track bug fixes up to the live site while sitting
on bigger, more untested changes.

I use Git when I'm releasing binaries to people (because I like its tagging
better) or when I have to track some upstream code and merge in some local
changes.

------
mmavnn
Fossil is also one of the few options when you're working on windows without
admin rights. Saved me from being completely without vcs in a couple of
previous job posts.

------
malkia
Github to git, is like Tarpit to fossil :)

Too bad tarpit.com is taken :(

~~~
dgroves
how about labrea.com then?

------
mdpm
... or just go install your own gitorius, and continue benefiting from all the
tooling support you already enjoy.

