15 ms·

Git vs. Fossil: what you should have done vs. what you did

75 points by hasheddan 5y ago

chmaynard 5y ago
Dr. Hipp seems to be trying hard to promote Fossil as superior to Git. Perhaps it is, but that ship has sailed already. He recently commented in an interview that Fossil is tailored and perfectly suited for the needs of the SQLite project. That's a strong argument in favor of Fossil and all he really needs to say on the topic.
- agbell 5y ago
  >"I looked at Git, I looked at Mercurial, and I looked at my requirements and I thought, “You know what? I’m just going to write my own,” so I wrote my own version control system, which is now a project unto itself, and that worked out very, very well, because think, Linus Torvalds wrote Git to support the Linux kernel, and it is perfectly designed to serve the needs of the Linux kernel development community. If you’re working on the Linux kernel, Git is absolutely the perfect version control system. >Now, if you’re working on something else, though, maybe not so much, and so, it’s a perfectly atrocious version control system for working for SQLite. >Fossil is absolutely the perfect version control system for working in SQLite, and I wrote it for that purpose, and so, because I wrote it myself, it exactly meets my needs and is the perfect product for what it’s doing, so by doing things yourself, you control your own destiny, you have more freedom, you’re not dependent upon third parties." https://corecursive.com/066-sqlite-with-richard-hipp/#building-fossil https://corecursive.com/066-sqlite-with-richard-hipp/#buildi...
- iso8859-1 5y ago
  Why does it matter if he can or cannot capture the majority of that market? The points can still be valid. A few thousand users is still a win for him.
  - agbell 5y ago
    Agreed and also it is valuable to not have a total monoculture. It's helpful to have people out and exploring other ways to do things.
  - sgbeal 5y ago
    > Why does it matter if he can or cannot capture the majority of that market? Amen to that. FWIW... i've actively contributed to fossil since 2008 and can say with some authority that we (the "regulars" on the project) have never done "PR pushes" for more users. It's simply not how any of us function. We welcome those who stop by, and we're happy to evangelize when approached, but we don't go actively hunting for more users. We're more of a "build it and they will come (or not)" project. Every couple of years someone pops up in the mailing list/forum proposing ways we could gain more users if we'd just do this and that and that other thing, but that's simply not a priority for any of us who actively work on Fossil. Continued work on Fossil is not about dominating the DVCS field (git has, for better or worse, long since done that). As Richard is quoted in earlier responses in this thread, Fossil is, first and foremost, a tool for maintaining sqlite. Similarly, i make use of Fossil for literally all of my own code because it's a great tool for the job, whereas git is... errr... less so. PS: the overwhelming majority of FOSS projects are far closer in size and scope to sqlite than they are to the Linux kernel (for which git was created).
    - mscrnt 5y ago
      > PS: the overwhelming majority of FOSS projects are far closer in size and scope to sqlite than they are to the Linux kernel (for which git was created). It's amusing if not ironic how many comments are something to the effect of "...but how messy and clumsy would the Fossil approach be when working with the Linux kernel that has 1000s of contributors pushing 1000s of commits..." when the sum total of projects approximating the size of the Linux kernel can be counted on one hand, and the authors of such comments are almost certainly not working on such projects. Not to mention the author of Fossil has clearly stated that Git is great for Linux kernel development, and Fossil was not developed for such a project.
- thunderbong 5y ago
  I didn't see it as such. It felt more like the approach that Fossil has towards maintaining history vs what Git has. I don't quite think it's a race to be won.
- pawelmurias 5y ago
  That's actually an argument in favor of git. SQLite has literally <= 3 developers.
  - SQLite 5y ago
    See https://www.sqlite.org/src/reports?type=ci&view=byuser https://www.sqlite.org/src/reports?type=ci&view=byuser SQLite has had about 33 contributors (after you combine people using multiple login names). But 92% of the commits have been from just two people. 97% from just three people. Then there is a long tail of other contributors. Fossil itself is similar: https://fossil-scm.org/home/reports?type=ci&view=byuser https://fossil-scm.org/home/reports?type=ci&view=byuser - 5 or 10 people account for most of the commits, and then there is a long tail. But aren't most projects like this? A few core developers are responsible for most changes and enhancements, and then there lots of others that might contribute a patch or two here and there? I suspect there exceptions to this (the Linux kernel comes to mind) but I think they are rare. Correct me if I'm wrong.
    - pawelmurias 5y ago
      Sqlite officially does not accept patches or contributions. There are very few projects that are openly hostile to contributors making sqlite unique. To be honest the link you posted shows it seems people have fixed some stuff (it seems mostly security holes and build fixes in the past).
      - SQLite 5y ago
        We accept (quality) patches and contributions from people who have completed the necessary paperwork to put their patches/contributions in the public domain. This restriction is in place so that that SQLite itself can remain in the public domain. If we accept drive-by patches from anonymous users, then SQLite would have to be relicensed as GPL or similar, which would undermine many of its use cases.
        athms 5y ago
- otherme123 5y ago
  It sounds to me like promoting SQLite itself. There are lots of people deploying Postgres and friends when their best DB for their case would be SQLite. In the same way, we are all using Git even for microprojects that would be better served with Fossil. I never had the impression of Dr. Hipp saying "Fossil > Git", but "Fossil might fit you better than Git".
- protomyth 5y ago
  I see it as more of a "don't try to use Fossil as Git or Git like Fossil". If you are just using them for code control for your own project, then this might tell you which fits your style.
rendall 5y ago
> Git strives to record what the development of a project should have looked like had there been no mistakes. Hmm. I think I disagree. One can clean the commit history to look like that, but it's optional. You can merge all of your messy starts and restarts right into master if you want. Easier to do, in fact.
- deleted 5y ago
  [deleted]
- wildmanx 5y ago
  But then you are on your own, tooling-wise.
- daniellarusso 5y ago
  One of the repos I interact with, the team rebases all their local branch commits to master. It is very difficult to read the commit history and get a sense of anything except Jira issue codes. One needs to look at the individual files and read the code to understand what the commit was for.
  - nerdponx 5y ago
    This is why the best Git workflows IMO involve rebasing and squashing the branch down to a couple of well-defined "logical commits", then merging that (with --no-ff of course) into master/main/trunk. This forces individual programmers to think somewhat carefully about leaving a sensible commit history behind.
  - jacoblambda 5y ago
    I think that's a consequence of rebasing. If you just merge instead, you can use the branching/merging to get a sense of complete features/changes.
    - nerdponx 5y ago
      Right, I think there's a bit of subtlety lost here. "Squash and merge to trunk" is very different from "rebase on every pull on a feature branch" which is very different from "rebase and fixup/squash before merging to trunk" etc. On a feature branch, whether you constantly rebase against master or merge from master probably should depend on the nature of the feature branch and what exactly has been happening on master. And it ultimately doesn't matter that much. In my experience, as long as branches are ultimately merged to master with --no-ff, you can almost always recover a sensible commit history, and you should almost always end up with a sensible, tidy master to base new branches off of. If you rebase with squash/fixup on the feature branch before merging, all the better, because then you get nice "meaningful" commits on the feature branch. But even if that doesn't happen and the feature branch is a mess, at least you could write a meaningful merge commit message. Maybe things get hairy with huge teams or huge projects that could necessitate a different workflow. But most developers are not working on projects like that.
chmod775 5y ago
Now imagine that you had the "mess" each contributor produced in the course of development in the history of the Linux Kernel - instead of just a clean set of final patches. That's what git was written for. On the other hand recording all the nitty gritty details might be nice for smaller projects.
- daniellarusso 5y ago
  I admit I have not looked at the kernel repo in quite awhile. Is rebase used with gitflow in that context?
  - formerly_proven 5y ago
    The kernel uses a patch-based workflow. Someone sends a bunch of patches to a list, gets feedback, improves on the patches, and sends the new set of patches. This might have added patches to the set, or changes to the existing patches. Repository write access is not (generally) shared between developers. This is a very, very different way of using git from how almost everyone else uses git.
- yoz-y 5y ago
  The cool thing with git is that nothing is preventing you from doing the latter. For small personal projects I don’t even care about small commits.
- wyoung2 5y ago
  That's section 2.5 in the same document: https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki#vs-linux https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.w...
hashhar 5y ago
> We don't look at this difference as a workaround in Fossil for autosync, but instead as a test-first philosophical difference: fossil commit is a commitment. When every commit is pushed to the parent repo by default, it encourages a working style in which every commit is tested first. It encourages thinking before acting. We believe this is an inherently good thing. I wonder how this works with tests that cannot be run locally (or ones that I'm not willing to sit through for the whole 1 hour the test suite runs for?)? Eager to hear from Fossil practicioners on this. The ideals do sound very good - but they remind me of the difference between an academic and a practicioner. One gets things done while the other advances the state of the field. Depends on what you like.
- hprotagonist 5y ago
  > The ideals do sound very good - but they remind me of the difference between an academic and a practicioner. Well, fossil is notably used for development of SQLite, which is about as practitioner-centric as it gets.
  - hashhar 5y ago
    Didn't know that. Thanks a lot for sharing this info. So I can take a look at some prior work of how it gets used in large projects and make sense of it.
- wyoung2 5y ago
  > tests that cannot be run locally Fossil just got a "patch" command to help with cases like that: https://fossil-scm.org/home/doc/trunk/www/patchcmd.md https://fossil-scm.org/home/doc/trunk/www/patchcmd.md Previously, the standard solution was to commit work with potential cross-platform issues to a short-lived experimental branch, so you can check out the branch on all your test machines and try it there before merging it down to trunk. > I'm not willing to sit through for the whole 1 hour the test suite runs for Hour-long test suite runs are a problem in and of themselves. That sets the shortest period of time your development organization can react to a test failure. Look to any application of control theory — feedback systems, process control, OODA loops... — for what happens when you have a slow-reacting feedback loop. One of those "guys who wrote the book" on Continuous Delivery covered the problem well here: https://www.davefarley.net/?p=218 https://www.davefarley.net/?p=218 You either need multiple levels of testing so you get some feedback quickly, or you need some sort of parallel build system that breaks the tests up so that the whole set completes in a reasonable amount of time. Without that, you're going to have people either sitting around waiting on test runners or skipping the tests entirely. > One gets things done Effort and resources spent on a massively parallel CD buildbot sounds like a good way to get things done to me. Computers are cheap; developer time is expensive.
hprotagonist 5y ago
long ago scott chacon said he didn’t use rebase and so i never learned how. i don’t feel that my commit history has suffered as a result.
- umvi 5y ago
  That's like saying "Long ago X said he didn't eat cruise ship buffet food, so I never do that either when I'm on a cruise. I don't feel my cruise ship experience has suffered as a result" It begs the question - how do you know it wouldn't improve your experience if you've never tried it?
  - hprotagonist 5y ago
    fair enough. ironically, i read “A supposedly fun thing I’ll never do again“ and subsequently resolved to never go on a cruise, either…
- mikepurvis 5y ago
  Like everything else in git, rebase feels like bits of seemingly-unrelated functionality bolted together, but I think I find basically all of the parts useful: - Rebasing my local changes onto remote updates has always felt safer and more natural than creating merge commits containing actual diffs. - The ability to trivially patch, drop, combine, and reorder commits has always felt like a superpower when it comes to telling the "story" of a change in a review, or breaking up a review into multiple smaller ones. - It's a bit more roundabout compared to just "edit", but if I want to amend a commit that isn't the HEAD, I often find it easier to just make a new commit with the desired change and then use rebase -i to move it up and squash it into where it needs to go.
echelon 5y ago
I don't understand all of the ceremony around keeping developer experimental checkpoints ("test", "fix", "fix2", "change name") around. If you really want to do this in git, you can. But there's little value in preserving this information. Keep the tiny commits, then squash when you merge to the main branch. You shouldn't have a feature branch for too long, so it won't be a problem. If there are merge commits, you can squash before rebase.
SPBS 5y ago
> In actual practice, the superior reporting tools available in Fossil mean that the added "mess" is not a factor. Okay, what tools are these? Fascinating to see how Fossil handles the commit mess.
- wyoung2 5y ago
  1. Fossil syncs branching and tagging info among all clones; it isn't local state as with Git. Therefore, when you're looking at a timeline, others' branches and such are named, labelled, and tagged. If you need to filter away all but your current branch, that's easy, because you have all the tags. If you need to see what others are up to in parallel with you so there isn't a big surprise at merge time, Fossil does that readily, too. 2. There's a "hide" feature in Fossil. Rather than destroy information, it simply marks a given branch as not-to-be-displayed unless you go out of your way to unhide everything. It's useful for branches that never go anywhere and thus need to be forgotten. 3. For the intermediate case, where you have a branch that shouldn't be forgotten but doesn't need to be in your face all the time, you can "close" it, meaning it still shows up in the timeline when you scroll far enough back in history to see it, but it's tagged so you can filter away all closed branches, leaving only what's active. This is the default mode for "fossil branch" without arguments, for instance, where it gives only the list of open branches. Your next command will almost certainly have a branch from that list, not something closed long ago. I could probably come up with more, but that should get you started.
umvi 5y ago
> When every commit is pushed to the parent repo by default, it encourages a working style in which every commit is tested first. It encourages thinking before acting. We believe this is an inherently good thing. Sounds like a bad thing to me. Sometimes I just want to make sure my work is saved in remote before quitting for the day, even if I haven't rigorously tested said changes.
- qmmmur 5y ago
  Yeah, I often do dummy commits with half-baked work just for fear of losing it. I don't work as a programmer so it doesn't really affect other people, but I don't see a way around it to be honest.
  - ashtonkem 5y ago
    Neither do most people who program for a living. WIP branches and “did I understand this ticket?” branches are the norm, not the exception.
    - wyoung2 5y ago
      That part of the article isn't talking about WIP branches, experimental branches, etc. My personal Fossil development philosophy is that you can go wild on those. The article's point applies primarily to long-lived development branches, things like what Git now calls "main", which Fossil calls "trunk". Commits to such branches should always build and pass all tests on all supported platforms.
      - temac 5y ago
        Serious projects with a non-trivial amont of people working on them don't rewrite the git history of "real" branches anyway, except maybe on very rare and targetted occasions (which are more to be understood as: let build a new repository with some resamblance to the old one) I could see projects with a very low number of devs AND users doing that, but even then they should probably not. Does that mean that all the tooling to cherry pick / rebase / filter / import-export patch series, shall disappear? Certainly not, because there are things that are _not_ main branches. An alternative could be to develop with completely different tooling, but I'm not sure what would be the point. So it actually looks like Fossil and Git basic good practices are quite similar, and I really don't see the point in pretending that the lack of support by fossils for some operations is an advantage. E.g. part of preparation of a good patch series suitable for a proper review often involves reordering, mixing and splitting commits. It is easier to do if the tooling does not actually try to prevent you from doing it because of some kind of misapplied dogma...
gwd 5y ago
This is obviously written by someone who's never done any sort of review-based workflow. Trying to review the "what you did" with all the random false starts, bug fixes, and who knows what, would be a nightmare; as would just reviewing the megapatch squashed from the end of the series. Presenting the final result of your "feature branch" as a series of self-contained changes in a logical order is the only sustainable model for a project of any size. EDIT: I really wanted to like Fossil when I first heard about it -- having it based on SQLite (which is AWESOME), having issue tracker / wiki / whatever built in, etc. sounded great. When I learned that it was basically incapable of rewriting your development branch into something more logical for someone to review because the author had never experienced a need for it I was quite disappointed.
- yxhuvud 5y ago
  I wouldn't mind if someone that understood this was involved in the PR review flow development of Github. Because that is clearly not the case.
- wojciechpolak 5y ago
  I wonder how they deal with the "bisect" flow? I use git bisect a lot and can't imagine how it would go with every WiP commit... (my answer: an unusable nightmare). Good luck with that.
  - krzyk 5y ago
    Why? It would be better, I frequently commit in. This way it is even easier to find the offending commit, because changes are smaller (yes, sometimes not working at all).
    - wojciechpolak 5y ago
      Because: "Fossil, in contrast, puts more emphasis on recording exactly what happened, including all of the messy errors..."
      - 5y ago
thunderbong 5y ago
From the article - >> One commentator characterized Git as recording history according to the victors, whereas Fossil records history as it actually happened.
- yxhuvud 5y ago
  What it doesn't explain is why on earth anyone should be interested in the latter.
  - thunderbong 5y ago
    Because software is honest?
Svip 5y ago
> Like Git, Fossil has an amend command for modifying prior commits, but unlike in Git, this works not by replacing data in the repository, but by adding a correction record to the repository that affects how later Fossil operations present the corrected data. I may be misreading this, but what if I accidentally commit (not push) a piece of sensitive data (say a private key), but notice before I commit. In Git, I would simply remove it, and amend, and it is now gone from the Git history. It sounds like with Fossil, it would remain in the history, or am I misunderstanding something? There are times where being able to rewrite the history is critical.
- badsectoracula 5y ago
  In Fossil it will remain in your local repository but you can put the hash for the data you accidentally committed in a "blacklist" so that it wont be pushed/pulled. I think you can also rebuild the local repository to purge any data, though i'm not 100% sure about that. (though you can certainly make a local clone of it which wont clone the blacklisted data, but you may need to manually copy/configure some stuff that aren't cloned)
- ashtonkem 5y ago
  Careful, amending doesn’t actually remove the bad commit, but it rather creates a new one and changes the appropriate branch pointer towards it. The old commit is still there, browsable if you know what you’re doing. This is fine if you’re doing it locally only, but incredibly misleading if you’ve already pushed the bad commit to a remote repository. It’s possible to remove sensitive data from Git, but it requires commands rarely used in a day to day workflow. It’s better to assume that any committed credential is burned and re-issue them.
- richie_adler 5y ago
  > what if I accidentally commit (not push) a piece of sensitive data (say a private key), but notice before I commit Fossil has autosync by default, so the commit has probably reached another instance anyway. But it has a provision exactly for those cases, the shunning mechanism. https://fossil-scm.org/home/doc/trunk/www/shunning.wiki https://fossil-scm.org/home/doc/trunk/www/shunning.wiki
badsectoracula 5y ago
I think the issue (which seems to exist in pretty much every VCS out there) is that there is a single flat timeline - even with branches (assuming they aren't treated as just separate parts of the tree) you get a single timeline per branch at best. Wouldn't it be better to be able to "nest" or "group" commits so that, e.g. all the "intermediate" commits go under the final commit which is what is displayed by default and "traveled" through via tools like log, blame, etc? Right now the best (though really not solving the issue) is to have a branch per task for VCSs where branching is trivial but this doesn't really solve it since you still get all the commits in your history anyway (i think some clients can display only the merge, but this is up to the tool, not an inherent feature). There was the other day a submission about a project on github where people noticed that the git history looked as if the author was making a new commit automatically every time he saved a source file and most comments were about how bad that it was. And i was thinking "Why? The issue here is that you can see those commits, not that they exist". You could easily have something like * Feature #1 submission * Feature #2 submission * Quick prototype hack * Save at 12/13/14 09:30 * Save at 12/13/14 09:31 * Save at 12/13/14 09:41 ... * Attempt #1 * Save at blahblah ... * Attempt #2 * Save at blahblah ... * Final Fix * Save at blahblah ... * Bug fix for #8923 * Attempt #1 * Review update * Etc and by default in the timeline/log you'd only see the top three commits until you drilled down, even to automated ones from file saves. Similarly when you looked at "blame" (or whatever) you'd see these commits. And of course all these tools should have a "max depth" (default 1) to allow you go into more detail. And yeah, you'd also need some functionality to specify and edit (preferably with its own history - Fossil already does that for other stuff like wiki) the parent/child relationships, perhaps with some current state (ie. under which commit all new commits will be placed). With something like that in place i do not see any reason to not keep as much as possible around.
- shawxe 5y ago
  I've been testing out a new workflow I'm Git in some personal projects that basically works like this. Basically, I make a single wip branch, which contains all of my messy/frequent commits, then when I feel that things are in a good state and I'm ready to cut a release off that branch, I tag that commit with "wip-vX.Y.Z". Separately, there is a "release" branch (which is basically master/main/trunk) that only ever gets code that was first committed into wip. When there's a new release tag in the wip branch, I run the following command on the release branch: "git cherry-pick -X theirs -n wip-vA.B.C..wip-vX.Y.Z", where A.B.C is the tag of the previous wip version and X.Y.Z is the tag of the current new wip version. This has the effect of taking all of those changes from the wip branch and staging them to be committed on the release branch. I then commit them with a descriptive commit message and tag that commit "release-vX.Y.Z". What you end up with, as a result, is a "release" branch with a very clean commit history and a "wip" branch with a very detailed commit history. If you want to run a more detailed blame or bisect, all you need to do is checkout the "wip" branch. If you want to use code that's stable enough to be called a release, all you need to do is checkout the "release" branch. Rather than squashing/amending wip commit history out of existence or maintaining on a series of scattered branches, this workflow makes it all conveniently available in one place, without directly polluting the main branch. As for the wip commits themselves, I do try to have them all be mostly atomic and to have them always build. But I feel much less concerned with having a couple of commits that try some idea then a couple more later on that undo it. Polluting a main branch with these sort of no-ops has never seemed particularly appealing to me, but not has simply deleting them, or tucking them away somewhere difficult to find. I've only been using this new workflow for a couple of weeks, but so far it seems to solve that problem and in general be working great.
Jsone 5y ago
I have to admit, in my career so far, I've never had to, or seen anyone have to, interact with a commit more than a sprint or two old. Almost all my workplaces enforced the usual standards regarding linear history, squash/rebases before PRs and commit naming, and then did absolutely nothing with the results of that effort. It probably means that I've had an atypical career, but I still wonder if all these ceremonies are as meaningful as we hold them to be.
- ComputerGuru 5y ago
  Working in open source, I’ve interacted with commits that predate git and were imported into it a decade ago, whether to track a bug, see how changes correlated, or check the historical behavior of a function. I couldn’t work without the ability to do so.
- badsectoracula 5y ago
  FWIW i often had to go backwards in history (that was with Perforce, not Git) in previous jobs to figure out when a bug was introduced and by who so i can see what was the logic behind the change (either from the commit message or by asking the person directly, if they were still around). It can be helpful to avoid breaking something else by mistake when trying to fix something that had a reason to be as it is.
- elliotbnvl 5y ago
  I haven't either, really. I suspect it's a matter of scale.
- throwaway_egbs 5y ago
  Same here, and I’ve worked at everything from mom-and-pops to a couple of household names. IME this (seemingly endless) discussion about how to manage commit history is the tabs-versus-spaces of source control.
- skybrian 5y ago
  For most projects, history gets used less and less the older it is. That's also true of the code. A lot gets abandoned or scarcely used. But for the most important, widely used, long-lived projects, things are different. You come to appreciate history when you have legacy code that you want to change and you'd like to figure out what the authors were thinking when they wrote it. (Unfortunately, too often, the version control history wasn't kept at all.) I think that we often assume our code is more important than it is, so we use ceremonies that aren't appropriate. But this is hard to judge in advance. The people writing long-lived code often didn't know that they were writing it.
thunderbong 5y ago
For me, version management, like IDEs are just tools that help a software developer towards their goal of *delivering* software. And, IMHO, towards that goal, Fossil does an incredible job. Besides this, Fossil is extremely comprehensive with respect to the additional things that a developer might use. It has an amazing timeline view, a wiki, a ticketing system, and now even chat. Again, I find the overall experience is way better than using Git, and all that from a single executable. More than once, while using Git, I've had to look up the arcane sequence of commands which I need to utter, to get out of a weird scenario. I've never had to do that with Fossil. Fossil, like it says elsewhere in the site, is a *sane* version management system. At least it keeps me sane! And lets me get on with my work!
VeejayRampay 5y ago
betamax of version control systems
voidfunc 5y ago
I always enjoy these threads because I get to hear about all the crazy git commands and workflows that people use besides (clone, commit, checkout, merge, pull, push).
aktiur 5y ago
Does it not come down to the usual "cathedral vs. bazar" opposition? SQLite, for which Fossil was originally built, lists 3 persons on its developers page and looks pretty much like the definition of a "cathedral", whereas git was built by Linus Torvalds for Linux, which is the prototypical bazar project. It makes sense when you have a small team of people that know the project very well to record everything, and they can easily maintain stringent standards, like never committing anything that breaks the tests. Whereas for a big project that involve thousands of people mailing patches around, some of them first time contributors, you'd rather make sure that what ends up in the immutable log has is clean enough.
- richie_adler 5y ago
  > Does it not come down to the usual "cathedral vs. bazar" opposition? This is expressly addressed in https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki (fifth row of the first table)
belter 5y ago
Here is a (somewhat old) talk by Richard Hipp, the author of SQLite about Git: "Richard Hipp - Git: Just Say No" https://youtu.be/ghtpJnrdgbo https://youtu.be/ghtpJnrdgbo I use Git every day, but I am curious about Fossil and have been researching it for a while. I am not planning on changing, as I need to get to the bottom of some data corruption events I have seen in their forums. Not saying it was the fault of Fossil, just that it requires more research on my side. We should not forget Version Management did not start with Git but has a vibrant history that began with SCCS, RCS, CVS, ClearCase, Perforce, SVN, etc... As I used all the systems above except for SCCS and RCS I would advise for some caution here on thinking Git core flows are the one true way. I know the authors of ClearCase though the same way :-) If the author of SQLite advances some arguments around the proper way of doing version management, I would advise to error on the side of caution and listen at least a second time. Do not throw away your own experience and insight, but at least listen carefully. Don't just dismiss the arguments as quickly as some are doing here. I found this recent thread very useful not only as a features comparison but also as a core reminder of what the main use case for Fossil is: "Lessons from 13+ Years of Fossil" : https://fossil-scm.org/forum/forumpost/22ca69016940d34299d52ae0c8caebae2f652e7709f0eae0689b82930c872d5e https://fossil-scm.org/forum/forumpost/22ca69016940d34299d52... "Fossil's reason for existence, plain and simple, is managing the source code for sqlite3. That's the scope of project it was initially envisioned for, and that size of project seems to be quite average for the FOSS world, falling clearly somewhere between "small" and "large." It does not scale well to projects with hundreds of thousands of files in any given version and/or tens of GB of data."
- richie_adler 5y ago
  That last paragraph should appease the critics who appear to be under the impression that Fossil is in a crusade to de-Gitify the universe. Strangely, it does not have that effect.
gorgoiler 5y ago
> Git records what the development should have looked like had there been no mistakes To be fair, for us mere-mortal programmers I never really know what I was trying to say until I’ve said it. At which point I revel in the opportunity to rebase, squash, fixup, and amend what I actually said into what I now realize I meant to say all along.
unanswered 5y ago
> You must do something drastic like git reset --hard to revert that rebase This betrays a deep failure to understand git; `git reset --hard` is one of the least "drastic" things you can do to a repository. It's certainly a lot less drastic than `git commit`, because it does a subset of the things `git commit` does. All `git reset --hard` does (to the repo, I mean; it also has working tree effects in yet another example of bad git UX) is point a branch to a different commit. `git checkout -B` is another way to accomplish the same thing, as is `git branch -f` (did I mention the bad UX?).
umvi 5y ago
I don't understand the obsession some VCS have (such as fossil and mercurial) with forcibly preventing the user from altering history. Even if it's intended to be a safety rail that prevents losing work, I should be the one that decides if I want the safety rail or not. Just like I should be able to run `sudo rm -rf /` on my computer if I want without some "mother-knows-best" OS preventing me from doing so. While the tool might be well-meaning and looking out for my best interests, I should have control at the end of the day, not the tool. Super contrived example: Say I'm writing an book in markdown and I'm using VCS to track changes. Maybe it's a private repo to start with, but I plan on eventually making it public and open source. Maybe it's a book that touches on racial issues, like "To Kill a Mockingbird". Maybe I don't want the whole world to be able to look back through iterations of paragraphs I wrote and rewrote over and over because I was trying to figure out how to strike the right tone. You're telling me with Fossil/Hg I can't ever truly erase mistakes I never intended people to see? What's stopping people from mining the repo's "trash commits", looking for offensive text to label me a racist on Twitter? With Git I'm in control and before I make it public I'll prune the private repo to throw away any trash commits I never intended people to see. With fossil I'd have to... create a brand new repo and rebuild it from the ground up with some automated tool that skips commits I don't want people to see? Or somehow use the "shunning" feature to painstakingly delete commits I don't want people to see? Fossil seems like a great fit for SQLite. Heck, seems like you use SQLite while using Fossil so it's like dogfooding (like using Git to version control Git). And I have never used fossil, so I can't knock it until I've tried it. But, I am reluctant to try it when I've already learned Git. I don't need wikis and chat and issue tracking or anything else fossil offers because I already use GitHub/Discord/etc for that (not to mention bundling all those things into a single executable is against the Unix philosophy, which I mostly subscribe to). However, I admit it is kind of cool that the wiki, issue tracking, chat, etc. are all just tables in the fossil repo so I guess theoretically you could easily search them with SQL commands.
renox 5y ago
> 2.6 One vs. Many Check-outs per Repository Given that git has worktree, it isn't limited to 'one checkout per repo'.. So I don't trust at all this comparison
crossroadsguy 5y ago
I’d love to have a robust and frictionless way for my working area (staged and un-staged) to be in sync with remote somehow on a press of some key combination. A remote backup/copy of edited files without involving an external backup tool. Stash is just local. Next best thing is a WIP commit but that I usually do at day end.

75 points by hasheddan 5y ago

Dr. Hipp seems to be trying hard to promote Fossil as superior to Git. Perhaps it is, but that ship has sailed already. He recently commented in an interview that Fossil is tailored and perfectly suited for the needs of the SQLite project. That's a strong argument in favor of Fossil and all he really needs to say on the topic.

agbell 5y ago
>"I looked at Git, I looked at Mercurial, and I looked at my requirements and I thought, “You know what? I’m just going to write my own,” so I wrote my own version control system, which is now a project unto itself, and that worked out very, very well, because think, Linus Torvalds wrote Git to support the Linux kernel, and it is perfectly designed to serve the needs of the Linux kernel development community. If you’re working on the Linux kernel, Git is absolutely the perfect version control system. >Now, if you’re working on something else, though, maybe not so much, and so, it’s a perfectly atrocious version control system for working for SQLite. >Fossil is absolutely the perfect version control system for working in SQLite, and I wrote it for that purpose, and so, because I wrote it myself, it exactly meets my needs and is the perfect product for what it’s doing, so by doing things yourself, you control your own destiny, you have more freedom, you’re not dependent upon third parties." https://corecursive.com/066-sqlite-with-richard-hipp/#building-fossil https://corecursive.com/066-sqlite-with-richard-hipp/#buildi...
iso8859-1 5y ago
Why does it matter if he can or cannot capture the majority of that market? The points can still be valid. A few thousand users is still a win for him.
- agbell 5y ago
  Agreed and also it is valuable to not have a total monoculture. It's helpful to have people out and exploring other ways to do things.
- sgbeal 5y ago
  > Why does it matter if he can or cannot capture the majority of that market? Amen to that. FWIW... i've actively contributed to fossil since 2008 and can say with some authority that we (the "regulars" on the project) have never done "PR pushes" for more users. It's simply not how any of us function. We welcome those who stop by, and we're happy to evangelize when approached, but we don't go actively hunting for more users. We're more of a "build it and they will come (or not)" project. Every couple of years someone pops up in the mailing list/forum proposing ways we could gain more users if we'd just do this and that and that other thing, but that's simply not a priority for any of us who actively work on Fossil. Continued work on Fossil is not about dominating the DVCS field (git has, for better or worse, long since done that). As Richard is quoted in earlier responses in this thread, Fossil is, first and foremost, a tool for maintaining sqlite. Similarly, i make use of Fossil for literally all of my own code because it's a great tool for the job, whereas git is... errr... less so. PS: the overwhelming majority of FOSS projects are far closer in size and scope to sqlite than they are to the Linux kernel (for which git was created).
  - mscrnt 5y ago
    > PS: the overwhelming majority of FOSS projects are far closer in size and scope to sqlite than they are to the Linux kernel (for which git was created). It's amusing if not ironic how many comments are something to the effect of "...but how messy and clumsy would the Fossil approach be when working with the Linux kernel that has 1000s of contributors pushing 1000s of commits..." when the sum total of projects approximating the size of the Linux kernel can be counted on one hand, and the authors of such comments are almost certainly not working on such projects. Not to mention the author of Fossil has clearly stated that Git is great for Linux kernel development, and Fossil was not developed for such a project.
thunderbong 5y ago
I didn't see it as such. It felt more like the approach that Fossil has towards maintaining history vs what Git has. I don't quite think it's a race to be won.
pawelmurias 5y ago
That's actually an argument in favor of git. SQLite has literally <= 3 developers.
- SQLite 5y ago
  See https://www.sqlite.org/src/reports?type=ci&view=byuser https://www.sqlite.org/src/reports?type=ci&view=byuser SQLite has had about 33 contributors (after you combine people using multiple login names). But 92% of the commits have been from just two people. 97% from just three people. Then there is a long tail of other contributors. Fossil itself is similar: https://fossil-scm.org/home/reports?type=ci&view=byuser https://fossil-scm.org/home/reports?type=ci&view=byuser - 5 or 10 people account for most of the commits, and then there is a long tail. But aren't most projects like this? A few core developers are responsible for most changes and enhancements, and then there lots of others that might contribute a patch or two here and there? I suspect there exceptions to this (the Linux kernel comes to mind) but I think they are rare. Correct me if I'm wrong.
  - pawelmurias 5y ago
    Sqlite officially does not accept patches or contributions. There are very few projects that are openly hostile to contributors making sqlite unique. To be honest the link you posted shows it seems people have fixed some stuff (it seems mostly security holes and build fixes in the past).
    - SQLite 5y ago
      We accept (quality) patches and contributions from people who have completed the necessary paperwork to put their patches/contributions in the public domain. This restriction is in place so that that SQLite itself can remain in the public domain. If we accept drive-by patches from anonymous users, then SQLite would have to be relicensed as GPL or similar, which would undermine many of its use cases.
      - athms 5y ago
otherme123 5y ago
It sounds to me like promoting SQLite itself. There are lots of people deploying Postgres and friends when their best DB for their case would be SQLite. In the same way, we are all using Git even for microprojects that would be better served with Fossil. I never had the impression of Dr. Hipp saying "Fossil > Git", but "Fossil might fit you better than Git".
protomyth 5y ago
I see it as more of a "don't try to use Fossil as Git or Git like Fossil". If you are just using them for code control for your own project, then this might tell you which fits your style.

rendall 5y ago

> Git strives to record what the development of a project should have looked like had there been no mistakes. Hmm. I think I disagree. One can clean the commit history to look like that, but it's optional. You can merge all of your messy starts and restarts right into master if you want. Easier to do, in fact.

deleted 5y ago
[deleted]
wildmanx 5y ago
But then you are on your own, tooling-wise.
daniellarusso 5y ago
One of the repos I interact with, the team rebases all their local branch commits to master. It is very difficult to read the commit history and get a sense of anything except Jira issue codes. One needs to look at the individual files and read the code to understand what the commit was for.
- nerdponx 5y ago
  This is why the best Git workflows IMO involve rebasing and squashing the branch down to a couple of well-defined "logical commits", then merging that (with --no-ff of course) into master/main/trunk. This forces individual programmers to think somewhat carefully about leaving a sensible commit history behind.
- jacoblambda 5y ago
  I think that's a consequence of rebasing. If you just merge instead, you can use the branching/merging to get a sense of complete features/changes.
  - nerdponx 5y ago
    Right, I think there's a bit of subtlety lost here. "Squash and merge to trunk" is very different from "rebase on every pull on a feature branch" which is very different from "rebase and fixup/squash before merging to trunk" etc. On a feature branch, whether you constantly rebase against master or merge from master probably should depend on the nature of the feature branch and what exactly has been happening on master. And it ultimately doesn't matter that much. In my experience, as long as branches are ultimately merged to master with --no-ff, you can almost always recover a sensible commit history, and you should almost always end up with a sensible, tidy master to base new branches off of. If you rebase with squash/fixup on the feature branch before merging, all the better, because then you get nice "meaningful" commits on the feature branch. But even if that doesn't happen and the feature branch is a mess, at least you could write a meaningful merge commit message. Maybe things get hairy with huge teams or huge projects that could necessitate a different workflow. But most developers are not working on projects like that.

chmod775 5y ago

Now imagine that you had the "mess" each contributor produced in the course of development in the history of the Linux Kernel - instead of just a clean set of final patches. That's what git was written for. On the other hand recording all the nitty gritty details might be nice for smaller projects.

daniellarusso 5y ago
I admit I have not looked at the kernel repo in quite awhile. Is rebase used with gitflow in that context?
- formerly_proven 5y ago
  The kernel uses a patch-based workflow. Someone sends a bunch of patches to a list, gets feedback, improves on the patches, and sends the new set of patches. This might have added patches to the set, or changes to the existing patches. Repository write access is not (generally) shared between developers. This is a very, very different way of using git from how almost everyone else uses git.
yoz-y 5y ago
The cool thing with git is that nothing is preventing you from doing the latter. For small personal projects I don’t even care about small commits.
wyoung2 5y ago
That's section 2.5 in the same document: https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki#vs-linux https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.w...

hashhar 5y ago

> We don't look at this difference as a workaround in Fossil for autosync, but instead as a test-first philosophical difference: fossil commit is a commitment. When every commit is pushed to the parent repo by default, it encourages a working style in which every commit is tested first. It encourages thinking before acting. We believe this is an inherently good thing. I wonder how this works with tests that cannot be run locally (or ones that I'm not willing to sit through for the whole 1 hour the test suite runs for?)? Eager to hear from Fossil practicioners on this. The ideals do sound very good - but they remind me of the difference between an academic and a practicioner. One gets things done while the other advances the state of the field. Depends on what you like.

hprotagonist 5y ago
> The ideals do sound very good - but they remind me of the difference between an academic and a practicioner. Well, fossil is notably used for development of SQLite, which is about as practitioner-centric as it gets.
- hashhar 5y ago
  Didn't know that. Thanks a lot for sharing this info. So I can take a look at some prior work of how it gets used in large projects and make sense of it.
wyoung2 5y ago
> tests that cannot be run locally Fossil just got a "patch" command to help with cases like that: https://fossil-scm.org/home/doc/trunk/www/patchcmd.md https://fossil-scm.org/home/doc/trunk/www/patchcmd.md Previously, the standard solution was to commit work with potential cross-platform issues to a short-lived experimental branch, so you can check out the branch on all your test machines and try it there before merging it down to trunk. > I'm not willing to sit through for the whole 1 hour the test suite runs for Hour-long test suite runs are a problem in and of themselves. That sets the shortest period of time your development organization can react to a test failure. Look to any application of control theory — feedback systems, process control, OODA loops... — for what happens when you have a slow-reacting feedback loop. One of those "guys who wrote the book" on Continuous Delivery covered the problem well here: https://www.davefarley.net/?p=218 https://www.davefarley.net/?p=218 You either need multiple levels of testing so you get some feedback quickly, or you need some sort of parallel build system that breaks the tests up so that the whole set completes in a reasonable amount of time. Without that, you're going to have people either sitting around waiting on test runners or skipping the tests entirely. > One gets things done Effort and resources spent on a massively parallel CD buildbot sounds like a good way to get things done to me. Computers are cheap; developer time is expensive.

hprotagonist 5y ago

long ago scott chacon said he didn’t use rebase and so i never learned how. i don’t feel that my commit history has suffered as a result.

umvi 5y ago
That's like saying "Long ago X said he didn't eat cruise ship buffet food, so I never do that either when I'm on a cruise. I don't feel my cruise ship experience has suffered as a result" It begs the question - how do you know it wouldn't improve your experience if you've never tried it?
- hprotagonist 5y ago
  fair enough. ironically, i read “A supposedly fun thing I’ll never do again“ and subsequently resolved to never go on a cruise, either…
mikepurvis 5y ago
Like everything else in git, rebase feels like bits of seemingly-unrelated functionality bolted together, but I think I find basically all of the parts useful: - Rebasing my local changes onto remote updates has always felt safer and more natural than creating merge commits containing actual diffs. - The ability to trivially patch, drop, combine, and reorder commits has always felt like a superpower when it comes to telling the "story" of a change in a review, or breaking up a review into multiple smaller ones. - It's a bit more roundabout compared to just "edit", but if I want to amend a commit that isn't the HEAD, I often find it easier to just make a new commit with the desired change and then use rebase -i to move it up and squash it into where it needs to go.

echelon 5y ago

I don't understand all of the ceremony around keeping developer experimental checkpoints ("test", "fix", "fix2", "change name") around. If you really want to do this in git, you can. But there's little value in preserving this information. Keep the tiny commits, then squash when you merge to the main branch. You shouldn't have a feature branch for too long, so it won't be a problem. If there are merge commits, you can squash before rebase.

SPBS 5y ago

> In actual practice, the superior reporting tools available in Fossil mean that the added "mess" is not a factor. Okay, what tools are these? Fascinating to see how Fossil handles the commit mess.

wyoung2 5y ago
1. Fossil syncs branching and tagging info among all clones; it isn't local state as with Git. Therefore, when you're looking at a timeline, others' branches and such are named, labelled, and tagged. If you need to filter away all but your current branch, that's easy, because you have all the tags. If you need to see what others are up to in parallel with you so there isn't a big surprise at merge time, Fossil does that readily, too. 2. There's a "hide" feature in Fossil. Rather than destroy information, it simply marks a given branch as not-to-be-displayed unless you go out of your way to unhide everything. It's useful for branches that never go anywhere and thus need to be forgotten. 3. For the intermediate case, where you have a branch that shouldn't be forgotten but doesn't need to be in your face all the time, you can "close" it, meaning it still shows up in the timeline when you scroll far enough back in history to see it, but it's tagged so you can filter away all closed branches, leaving only what's active. This is the default mode for "fossil branch" without arguments, for instance, where it gives only the list of open branches. Your next command will almost certainly have a branch from that list, not something closed long ago. I could probably come up with more, but that should get you started.

umvi 5y ago

> When every commit is pushed to the parent repo by default, it encourages a working style in which every commit is tested first. It encourages thinking before acting. We believe this is an inherently good thing. Sounds like a bad thing to me. Sometimes I just want to make sure my work is saved in remote before quitting for the day, even if I haven't rigorously tested said changes.

qmmmur 5y ago
Yeah, I often do dummy commits with half-baked work just for fear of losing it. I don't work as a programmer so it doesn't really affect other people, but I don't see a way around it to be honest.
- ashtonkem 5y ago
  Neither do most people who program for a living. WIP branches and “did I understand this ticket?” branches are the norm, not the exception.
  - wyoung2 5y ago
    That part of the article isn't talking about WIP branches, experimental branches, etc. My personal Fossil development philosophy is that you can go wild on those. The article's point applies primarily to long-lived development branches, things like what Git now calls "main", which Fossil calls "trunk". Commits to such branches should always build and pass all tests on all supported platforms.
    - temac 5y ago
      Serious projects with a non-trivial amont of people working on them don't rewrite the git history of "real" branches anyway, except maybe on very rare and targetted occasions (which are more to be understood as: let build a new repository with some resamblance to the old one) I could see projects with a very low number of devs AND users doing that, but even then they should probably not. Does that mean that all the tooling to cherry pick / rebase / filter / import-export patch series, shall disappear? Certainly not, because there are things that are _not_ main branches. An alternative could be to develop with completely different tooling, but I'm not sure what would be the point. So it actually looks like Fossil and Git basic good practices are quite similar, and I really don't see the point in pretending that the lack of support by fossils for some operations is an advantage. E.g. part of preparation of a good patch series suitable for a proper review often involves reordering, mixing and splitting commits. It is easier to do if the tooling does not actually try to prevent you from doing it because of some kind of misapplied dogma...

gwd 5y ago

This is obviously written by someone who's never done any sort of review-based workflow. Trying to review the "what you did" with all the random false starts, bug fixes, and who knows what, would be a nightmare; as would just reviewing the megapatch squashed from the end of the series. Presenting the final result of your "feature branch" as a series of self-contained changes in a logical order is the only sustainable model for a project of any size. EDIT: I really wanted to like Fossil when I first heard about it -- having it based on SQLite (which is AWESOME), having issue tracker / wiki / whatever built in, etc. sounded great. When I learned that it was basically incapable of rewriting your development branch into something more logical for someone to review because the author had never experienced a need for it I was quite disappointed.

yxhuvud 5y ago
I wouldn't mind if someone that understood this was involved in the PR review flow development of Github. Because that is clearly not the case.
wojciechpolak 5y ago
I wonder how they deal with the "bisect" flow? I use git bisect a lot and can't imagine how it would go with every WiP commit... (my answer: an unusable nightmare). Good luck with that.
- krzyk 5y ago
  Why? It would be better, I frequently commit in. This way it is even easier to find the offending commit, because changes are smaller (yes, sometimes not working at all).
  - wojciechpolak 5y ago
    Because: "Fossil, in contrast, puts more emphasis on recording exactly what happened, including all of the messy errors..."
    - 5y ago

thunderbong 5y ago

From the article - >> One commentator characterized Git as recording history according to the victors, whereas Fossil records history as it actually happened.

yxhuvud 5y ago
What it doesn't explain is why on earth anyone should be interested in the latter.
- thunderbong 5y ago
  Because software is honest?

Svip 5y ago

> Like Git, Fossil has an amend command for modifying prior commits, but unlike in Git, this works not by replacing data in the repository, but by adding a correction record to the repository that affects how later Fossil operations present the corrected data. I may be misreading this, but what if I accidentally commit (not push) a piece of sensitive data (say a private key), but notice before I commit. In Git, I would simply remove it, and amend, and it is now gone from the Git history. It sounds like with Fossil, it would remain in the history, or am I misunderstanding something? There are times where being able to rewrite the history is critical.

badsectoracula 5y ago
In Fossil it will remain in your local repository but you can put the hash for the data you accidentally committed in a "blacklist" so that it wont be pushed/pulled. I think you can also rebuild the local repository to purge any data, though i'm not 100% sure about that. (though you can certainly make a local clone of it which wont clone the blacklisted data, but you may need to manually copy/configure some stuff that aren't cloned)
ashtonkem 5y ago
Careful, amending doesn’t actually remove the bad commit, but it rather creates a new one and changes the appropriate branch pointer towards it. The old commit is still there, browsable if you know what you’re doing. This is fine if you’re doing it locally only, but incredibly misleading if you’ve already pushed the bad commit to a remote repository. It’s possible to remove sensitive data from Git, but it requires commands rarely used in a day to day workflow. It’s better to assume that any committed credential is burned and re-issue them.
richie_adler 5y ago
> what if I accidentally commit (not push) a piece of sensitive data (say a private key), but notice before I commit Fossil has autosync by default, so the commit has probably reached another instance anyway. But it has a provision exactly for those cases, the shunning mechanism. https://fossil-scm.org/home/doc/trunk/www/shunning.wiki https://fossil-scm.org/home/doc/trunk/www/shunning.wiki

badsectoracula 5y ago

I think the issue (which seems to exist in pretty much every VCS out there) is that there is a single flat timeline - even with branches (assuming they aren't treated as just separate parts of the tree) you get a single timeline per branch at best. Wouldn't it be better to be able to "nest" or "group" commits so that, e.g. all the "intermediate" commits go under the final commit which is what is displayed by default and "traveled" through via tools like log, blame, etc? Right now the best (though really not solving the issue) is to have a branch per task for VCSs where branching is trivial but this doesn't really solve it since you still get all the commits in your history anyway (i think some clients can display only the merge, but this is up to the tool, not an inherent feature). There was the other day a submission about a project on github where people noticed that the git history looked as if the author was making a new commit automatically every time he saved a source file and most comments were about how bad that it was. And i was thinking "Why? The issue here is that you can see those commits, not that they exist". You could easily have something like * Feature #1 submission * Feature #2 submission * Quick prototype hack * Save at 12/13/14 09:30 * Save at 12/13/14 09:31 * Save at 12/13/14 09:41 ... * Attempt #1 * Save at blahblah ... * Attempt #2 * Save at blahblah ... * Final Fix * Save at blahblah ... * Bug fix for #8923 * Attempt #1 * Review update * Etc and by default in the timeline/log you'd only see the top three commits until you drilled down, even to automated ones from file saves. Similarly when you looked at "blame" (or whatever) you'd see these commits. And of course all these tools should have a "max depth" (default 1) to allow you go into more detail. And yeah, you'd also need some functionality to specify and edit (preferably with its own history - Fossil already does that for other stuff like wiki) the parent/child relationships, perhaps with some current state (ie. under which commit all new commits will be placed). With something like that in place i do not see any reason to not keep as much as possible around.

shawxe 5y ago
I've been testing out a new workflow I'm Git in some personal projects that basically works like this. Basically, I make a single wip branch, which contains all of my messy/frequent commits, then when I feel that things are in a good state and I'm ready to cut a release off that branch, I tag that commit with "wip-vX.Y.Z". Separately, there is a "release" branch (which is basically master/main/trunk) that only ever gets code that was first committed into wip. When there's a new release tag in the wip branch, I run the following command on the release branch: "git cherry-pick -X theirs -n wip-vA.B.C..wip-vX.Y.Z", where A.B.C is the tag of the previous wip version and X.Y.Z is the tag of the current new wip version. This has the effect of taking all of those changes from the wip branch and staging them to be committed on the release branch. I then commit them with a descriptive commit message and tag that commit "release-vX.Y.Z". What you end up with, as a result, is a "release" branch with a very clean commit history and a "wip" branch with a very detailed commit history. If you want to run a more detailed blame or bisect, all you need to do is checkout the "wip" branch. If you want to use code that's stable enough to be called a release, all you need to do is checkout the "release" branch. Rather than squashing/amending wip commit history out of existence or maintaining on a series of scattered branches, this workflow makes it all conveniently available in one place, without directly polluting the main branch. As for the wip commits themselves, I do try to have them all be mostly atomic and to have them always build. But I feel much less concerned with having a couple of commits that try some idea then a couple more later on that undo it. Polluting a main branch with these sort of no-ops has never seemed particularly appealing to me, but not has simply deleting them, or tucking them away somewhere difficult to find. I've only been using this new workflow for a couple of weeks, but so far it seems to solve that problem and in general be working great.

Jsone 5y ago

I have to admit, in my career so far, I've never had to, or seen anyone have to, interact with a commit more than a sprint or two old. Almost all my workplaces enforced the usual standards regarding linear history, squash/rebases before PRs and commit naming, and then did absolutely nothing with the results of that effort. It probably means that I've had an atypical career, but I still wonder if all these ceremonies are as meaningful as we hold them to be.

ComputerGuru 5y ago
Working in open source, I’ve interacted with commits that predate git and were imported into it a decade ago, whether to track a bug, see how changes correlated, or check the historical behavior of a function. I couldn’t work without the ability to do so.
badsectoracula 5y ago
FWIW i often had to go backwards in history (that was with Perforce, not Git) in previous jobs to figure out when a bug was introduced and by who so i can see what was the logic behind the change (either from the commit message or by asking the person directly, if they were still around). It can be helpful to avoid breaking something else by mistake when trying to fix something that had a reason to be as it is.
elliotbnvl 5y ago
I haven't either, really. I suspect it's a matter of scale.
throwaway_egbs 5y ago
Same here, and I’ve worked at everything from mom-and-pops to a couple of household names. IME this (seemingly endless) discussion about how to manage commit history is the tabs-versus-spaces of source control.
skybrian 5y ago
For most projects, history gets used less and less the older it is. That's also true of the code. A lot gets abandoned or scarcely used. But for the most important, widely used, long-lived projects, things are different. You come to appreciate history when you have legacy code that you want to change and you'd like to figure out what the authors were thinking when they wrote it. (Unfortunately, too often, the version control history wasn't kept at all.) I think that we often assume our code is more important than it is, so we use ceremonies that aren't appropriate. But this is hard to judge in advance. The people writing long-lived code often didn't know that they were writing it.

thunderbong 5y ago

For me, version management, like IDEs are just tools that help a software developer towards their goal of *delivering* software. And, IMHO, towards that goal, Fossil does an incredible job. Besides this, Fossil is extremely comprehensive with respect to the additional things that a developer might use. It has an amazing timeline view, a wiki, a ticketing system, and now even chat. Again, I find the overall experience is way better than using Git, and all that from a single executable. More than once, while using Git, I've had to look up the arcane sequence of commands which I need to utter, to get out of a weird scenario. I've never had to do that with Fossil. Fossil, like it says elsewhere in the site, is a *sane* version management system. At least it keeps me sane! And lets me get on with my work!

VeejayRampay 5y ago

betamax of version control systems

voidfunc 5y ago

I always enjoy these threads because I get to hear about all the crazy git commands and workflows that people use besides (clone, commit, checkout, merge, pull, push).

aktiur 5y ago

Does it not come down to the usual "cathedral vs. bazar" opposition? SQLite, for which Fossil was originally built, lists 3 persons on its developers page and looks pretty much like the definition of a "cathedral", whereas git was built by Linus Torvalds for Linux, which is the prototypical bazar project. It makes sense when you have a small team of people that know the project very well to record everything, and they can easily maintain stringent standards, like never committing anything that breaks the tests. Whereas for a big project that involve thousands of people mailing patches around, some of them first time contributors, you'd rather make sure that what ends up in the immutable log has is clean enough.

richie_adler 5y ago
> Does it not come down to the usual "cathedral vs. bazar" opposition? This is expressly addressed in https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki https://fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki (fifth row of the first table)

belter 5y ago

Here is a (somewhat old) talk by Richard Hipp, the author of SQLite about Git: "Richard Hipp - Git: Just Say No" https://youtu.be/ghtpJnrdgbo https://youtu.be/ghtpJnrdgbo I use Git every day, but I am curious about Fossil and have been researching it for a while. I am not planning on changing, as I need to get to the bottom of some data corruption events I have seen in their forums. Not saying it was the fault of Fossil, just that it requires more research on my side. We should not forget Version Management did not start with Git but has a vibrant history that began with SCCS, RCS, CVS, ClearCase, Perforce, SVN, etc... As I used all the systems above except for SCCS and RCS I would advise for some caution here on thinking Git core flows are the one true way. I know the authors of ClearCase though the same way :-) If the author of SQLite advances some arguments around the proper way of doing version management, I would advise to error on the side of caution and listen at least a second time. Do not throw away your own experience and insight, but at least listen carefully. Don't just dismiss the arguments as quickly as some are doing here. I found this recent thread very useful not only as a features comparison but also as a core reminder of what the main use case for Fossil is: "Lessons from 13+ Years of Fossil" : https://fossil-scm.org/forum/forumpost/22ca69016940d34299d52ae0c8caebae2f652e7709f0eae0689b82930c872d5e https://fossil-scm.org/forum/forumpost/22ca69016940d34299d52... "Fossil's reason for existence, plain and simple, is managing the source code for sqlite3. That's the scope of project it was initially envisioned for, and that size of project seems to be quite average for the FOSS world, falling clearly somewhere between "small" and "large." It does not scale well to projects with hundreds of thousands of files in any given version and/or tens of GB of data."

richie_adler 5y ago
That last paragraph should appease the critics who appear to be under the impression that Fossil is in a crusade to de-Gitify the universe. Strangely, it does not have that effect.

gorgoiler 5y ago

> Git records what the development should have looked like had there been no mistakes To be fair, for us mere-mortal programmers I never really know what I was trying to say until I’ve said it. At which point I revel in the opportunity to rebase, squash, fixup, and amend what I actually said into what I now realize I meant to say all along.

unanswered 5y ago

> You must do something drastic like git reset --hard to revert that rebase This betrays a deep failure to understand git; `git reset --hard` is one of the least "drastic" things you can do to a repository. It's certainly a lot less drastic than `git commit`, because it does a subset of the things `git commit` does. All `git reset --hard` does (to the repo, I mean; it also has working tree effects in yet another example of bad git UX) is point a branch to a different commit. `git checkout -B` is another way to accomplish the same thing, as is `git branch -f` (did I mention the bad UX?).

umvi 5y ago

I don't understand the obsession some VCS have (such as fossil and mercurial) with forcibly preventing the user from altering history. Even if it's intended to be a safety rail that prevents losing work, I should be the one that decides if I want the safety rail or not. Just like I should be able to run `sudo rm -rf /` on my computer if I want without some "mother-knows-best" OS preventing me from doing so. While the tool might be well-meaning and looking out for my best interests, I should have control at the end of the day, not the tool. Super contrived example: Say I'm writing an book in markdown and I'm using VCS to track changes. Maybe it's a private repo to start with, but I plan on eventually making it public and open source. Maybe it's a book that touches on racial issues, like "To Kill a Mockingbird". Maybe I don't want the whole world to be able to look back through iterations of paragraphs I wrote and rewrote over and over because I was trying to figure out how to strike the right tone. You're telling me with Fossil/Hg I can't ever truly erase mistakes I never intended people to see? What's stopping people from mining the repo's "trash commits", looking for offensive text to label me a racist on Twitter? With Git I'm in control and before I make it public I'll prune the private repo to throw away any trash commits I never intended people to see. With fossil I'd have to... create a brand new repo and rebuild it from the ground up with some automated tool that skips commits I don't want people to see? Or somehow use the "shunning" feature to painstakingly delete commits I don't want people to see? Fossil seems like a great fit for SQLite. Heck, seems like you use SQLite while using Fossil so it's like dogfooding (like using Git to version control Git). And I have never used fossil, so I can't knock it until I've tried it. But, I am reluctant to try it when I've already learned Git. I don't need wikis and chat and issue tracking or anything else fossil offers because I already use GitHub/Discord/etc for that (not to mention bundling all those things into a single executable is against the Unix philosophy, which I mostly subscribe to). However, I admit it is kind of cool that the wiki, issue tracking, chat, etc. are all just tables in the fossil repo so I guess theoretically you could easily search them with SQL commands.

renox 5y ago

> 2.6 One vs. Many Check-outs per Repository Given that git has worktree, it isn't limited to 'one checkout per repo'.. So I don't trust at all this comparison

crossroadsguy 5y ago

I’d love to have a robust and frictionless way for my working area (staged and un-staged) to be in sync with remote somehow on a press of some key combination. A remote backup/copy of edited files without involving an external backup tool. Stash is just local. Next best thing is a WIP commit but that I usually do at day end.