26 ms·

Why SQLite Does Not Use Git

508 points by trextrex 8y ago

lclarkmichalek 8y ago
2, 4, 5, and 6 seem pretty weak. Not a particularly interesting article. Mostly comes down to 'we like X and Y about Fossil, and it works for us, so we use it instead'.
- btgeekboy 8y ago
  There’s certainly nothing wrong with that position though. If another tool fits their workflow better, then that’s what they should use.
- arunc 8y ago
  2,3,5: very valid and the reason why we use Mercurial instead. Can't afford to hire a Git guru in every team. Instead we use a tool that's easier for everyone.
  - vangar 8y ago
    Once you start adding more than one developer to a Mercurial repo you need to know how Mercurial works, so I don't see how this is much different. In fact adding remotes to Mercurial was a much harder process last time I used it.
    - arunc 8y ago
      The point is, Mercurial is much easier learn. We are a team of 20 developers distributed across globe that transitioned from SVN and it was easy for us to pick up Mercurial and start using it within a couple of days. We tried git too and lost our changes inevitably. Our git knowledge is to be blamed but blame git CLI too! It is not easy to learn at all. After 12 years of git, I see articles with tips and guides on using git. That kind of hints how esoteric git CLI can be.
      - vangar 8y ago
        SmartGit is extremely useful, i'd recommend something like that instead of using the CLI if you have trouble.
      - zenhack 8y ago
        I feel like most of the trouble developers have with Git is pretty shallow, and it's a shame. It's not a tool I would want to get non-programmers to use (which may be a problem if you've got design folks on your team as well), but the model should be pretty learnable (in principle) to anyone who can manage to hobble their way through an intro data structures course. For folks like me, who spent their evenings in high-school screwing around with obscure linux distros and have been scouring badly written man pages trying to fix their computer for half their life, the little stuff is forgivable, and a lot of the big stuff is pretty good. But it's a shame how many inessential hurdles there are. See also: https://git-man-page-generator.lokaltog.net/ https://git-man-page-generator.lokaltog.net/ Biggest piece of advice for not losing data: learn about git-reflog and git-reset before doing anything that modifies history. Nothing is destroyed, even by "scary" operations like rebase, so it's always possible to recover something, but you need to know how to find stuff. I do some contract work for a university, where we have lots of student interns going through. We use GitHub, and we rarely rebase or cherry-pick, basically because while I could spend a bunch of time trying to teach git to new interns that will be gone in 4 months, It seems like a more efficient use of time to just occasionally put up with a messy history.
neals 8y ago
I'm a big fan of Fossil myself. But the SQlite people have something that I don't really have within the teams I operate : the authority to dare and speak out against Git and not be laughed away like a hipster that is just trying to be different.
- matt_wulfeck 8y ago
  Git is a use-case that is excellent for 90% of development. Sqlite is just an example where the use-case isn't necessarily ideal, not an indicator that it's "better" than git.
  - bch 8y ago
    I’m a fossil fan. I’d say that git is fine for 90% of development (or some arbitrarily large number), but so is fossil. I don’t even think that SQLite-in-git would necessarily be a deal-breaker that couldn’t be worked around (drh ‘sqlite can chime in here). The whole space (from personal projects to global collaboration) is diverse enough that there’s no talking about “better” without qualifying the situation, either. Fossil is good for a large subset of work that can benefit from source control management, regardless of git. What git definately has is 1) scaleabilty, which is probably of no consequence for 99% of the cases it is employed 2) network effect, for better AND worse
    - nebulous1 8y ago
      > drh ‘sqlite can chime in here He already has > With Git, it is very difficult to find the successors (decendents) of a check-in ... This is a deal-breaker, a show-stopper.
      - deleted 8y ago
        [deleted]
      - AstralStorm 8y ago
        Someone still thinks in the single main branch mode. It is sometimes the main case but definitely not in git world. This operation is not easy in any DAG. It involves: - find all or desired branch tips - walk backwards until hitting tge desired checkin - memoize already seen parents to not walk them multiple times
crispyporkbites 8y ago
> Fossil and Git are both block-chain version-control systems Wow, we have gone full circle. Can’t wait for Linus to announce the git ICO!
- roywiggins 8y ago
  GitCoin
  - tlrobinson 8y ago
    In fact "GitCoin" was one of the levels in Stripe's distributed systems CTF in 2014: https://github.com/ctfs/write-ups-2014/tree/master/stripe-ctf3/level1 https://github.com/ctfs/write-ups-2014/tree/master/stripe-ct...
  - glitch003 8y ago
    >GitCoin Gitcoin is the name of a real blockchain project that let's people put ethereum bounties on their github issues. https://gitcoin.co/ https://gitcoin.co/ (Slightly off topic, sorry)
- rwbt 8y ago
  Technically Dr. Richard Hipp is right https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg26593.html https://www.mail-archive.com/fossil-users@lists.fossil-scm.o...
  - jancsika 8y ago
    > So, why can't we rebrand fossil as Blockchain-VCS or something and move on toward world domination? Because Fossil-- like Git-- doesn't solve, attempt to solve, or even advertise itself as solving the problem of decentralized consensus. All existing blockchain technologies at least claim to be a solution to the problem of decentralized consensus. Therefore Dr. Richard Hipp is only "technically" right in the ways that do not matter, in the same way that I'm "technically" doing functional programming any time I write a javascript function. I assume he knows this and is being satirical.
  - 8y ago
deedubaya 8y ago
I don't know anything about Fossil, but saying that no one understands Git just makes me think they're ignorant to learning Git. I doubt that's the case, but still, why say that?
- crispyporkbites 8y ago
  Because most users of git don’t really understand it. It’s really hard to learn properly and so most users just memorize the commands for their project’s workflow and ask the resident git expert to help (or nuke their local copy) when things go wrong.
  - philwelch 8y ago
    It’s not hard to “really understand Git”. If anything, it’s the opposite problem—Git’s implementation is conceptually simple enough that the only good mental model the end user could possibly have is the implementation model. Systems like Subversion or Perforce or Fossil probably have even more complicated implementations than Git, and largely that’s to support a dumbed-down mental model that doesn’t require learning how the tool actually works. With Git, you learn how it works and you’re set, more or less.
    - ropeadopepope 8y ago
      > It’s not hard to “really understand Git”. Are you going to tell me you've never lost work because you didn't know git well enough to avoid putting your branch into a bad state?
      - philwelch 8y ago
        I’ve never lost work that I committed, which is the most you can ask of a version control system.
        ropeadopepope 8y ago
        You've never botched a merge, try to undo it and accidentally lost work? It's happened to me and/or the people I work with roughly once a quarter since I started using git.
monocasa 8y ago
It's funny that they don't list the real reason, which is that Fossil is built on top of SQLite and they want to dogfood it.
- rwbt 8y ago
  SQLite is tested extensively fossil or not. Short of military software it's probably the most tested piece of software.
  - monocasa 8y ago
    There are reasons to dogfood that aren't 'does it pass integration tests'. Stuff like 'is it to hard to use this feature in a real way', and 'performance bottlenecks that you might not have thought of'.
- jopsen 8y ago
  And the real reason to use git is that everybody else uses git.
  - kadenshep 8y ago
    Everybody uses git because it's the most sane and powerful source control tool there is.
    - PowerRangError 8y ago
      Why do you think it's "the most" when there are equivalents? What does "most" mean? Most used was the point and the only salient quality that fits.
      - parvenu74 8y ago
        This is a great question. Where I work we use TFSVC and the VP of Engineering is willing to green-light a switch to Git as long as we can make a data-driven, objective case for why Git is better. In other words: "the devs prefer it" or "using Git makes me happier" don't wash as valid reasons. Branching in Git is certainly much easier but the counter that "you can branch with TFSVC too" is true, even if it's slower and eats up your hard drive space faster...
wiremine 8y ago
Good list, but I feel like they bury the lede: integrated wiki, issues, and notes. That doesn't scale to every project (linux kernel for example), but for a lot of projects it's really cool. Other selling points from the Fossil site: * Integrated Bug Tracking, Wiki, and Technotes * Built-in Web Interface _and_ Self-Contained (I combined these) * Simple Networking (no git://, just HTTP and SSH) * CGI/SCGI Enabled * Autosync - "Fossil supports "autosync" mode which helps to keep projects moving forward by reducing the amount of needless forking and merging often associated with distributed projects." * Robust & Reliable - "Fossil stores content using an enduring file format in an SQLite database so that transactions are atomic even if interrupted by a power loss or system crash. Automatic self-checks verify that all aspects of the repository are consistent prior to each commit." It would be easy to get into comparing git and Fossil feature by feature. That's interesting. But it's more interesting to compare the philosophies between the two tools. edit: for grammer.
- syedkarim 8y ago
  grammar
- ccostes 8y ago
  > But it's more interesting to compare the philosophies between the two tools. So what are their philosophies? Fossil is for small things and git is for scalability?
  - shagie 8y ago
    Git is a filesystem ( https://git-scm.com/book/en/v2/Git-Internals-Git-Objects https://git-scm.com/book/en/v2/Git-Internals-Git-Objects ). > Git is a content-addressable filesystem. Great. What does that mean? It means that at the core of Git is a simple key-value data store. What this means is that you can insert any kind of content into a Git repository, for which Git will hand you back a unique key you can use later to retrieve that content. That's a great thing for matching the mindset of someone writing operating system software. Fossil is on top of a relational database... which is also a great thing for matching the mindset of someone writing a relational database.
- 8y ago
vangar 8y ago
"The mental model for Git is needlessly complex and consequently distracts attention from software under development. A user of Git needs to keep all of the following in mind: The working directory The "index" or staging area The local head The local copy of the remote head The actual remote head Git contains commands (or options on commands) for moving and comparing content between all of these locations. In contrast, Fossil users only need to think about their working directory and the check-in they are working on. That is 60% less distraction." I don't think about any of this when developing. I check out a branch, work on it, commit to it, and push it back up. If the fix is larger than a few commits i'll make a feature branch. What's so hard about that? Also, everyone using git isn't a bad thing. It means we finally have at least one standard in development.
- wvenable 8y ago
  I feel like everyone using git is like everyone using C.
  - dimman 8y ago
    Fortunately for us C programmers then that not everyone has come to their senses.
- psyc 8y ago
  You get git. Good for you. A lot of smart people get git. A lot of smart people don't. I'm a smart person. I use git every day, 7 days a week. On my side projects, it's fine. Never a problem. At work, the workflow is more complicated, due to many branches, and many submodules. Submodules are a pain in practice. I think the mental model is too complex. This manifests as frequent unintended results, from simple operations that in my mind need not have unintended consequences. I never had any such problem with Perforce, even though I have used git twice as long. Your mileage obviously varies.
  - kadenshep 8y ago
    >A lot of smart people don't. I'm sorry, I don't buy this at all. Git is one of the most simple source control tools there is. If you can't understand a DAG then there isn't much else you probably can understand in the development world. >This manifests as frequent unintended results No it doesn't. Every time I've seen people complain about "unintended results" it's literally been because of the above, and they've been complete morons so I'm never surprised when these people have "trouble" with git. You're building a graph, and you're doing pretty basic manipulation of that graph. >I never had any such problem with Perforce Uh what? Permission issues? Terrible branch performance? Merging between branches is basically a gamble -- it's actually insane how much this used to mess up over the most basic of merges. Having to "upgrade" the system? Ever done that. I'm going to guess no.
lifeisstillgood 8y ago
>>> The principle maintainer of SQLite cannot function effectively without being able to view the successors of a check-in. This one issue is sufficient reason to not use Git, in the view of the designer of SQLite Ok I'll bite. Why? I can see it's a nice idea - but at some point you add function X, then ten check ins modify that function. what's the difference between looking back at ten and looking forward at ten? Perhaps I need an example. If I remember rightly fossil was written by the Sqllite people? I tried it out for a while back in the day - I think it had this store the tickets in the branch alongside the code - it was an appealing idea, but got complicated quickly.
- ozten 8y ago
  Purely speculative, but I imagine you identify a bug that was introduced in commit X from 2 years ago. You want to answer, "Which supported releases of this product need to be patched?".
  - tbodt 8y ago
    git tag --contains <commit> or git branch --contains <commit>
  - aoeusnth1 8y ago
    isn't that just a question of looping over your release tags and asking whether each one can reach that commit? It's not too hard to script - I don't really see an advantage either way.
ccostes 8y ago
Interesting, I hadn't heard of Fossil before. It is useful to have a 'lingua franca' of open-source version control, but I'm not sure git is necessarily the best choice for that (not that network-effects usually result in the 'best' being chosen)
occams_chainsaw 8y ago
Git does not track branch history. This makes review of historical branches tedious. This isn't true. It's just the Fossil example has a better UI than their github example. Pop open gitk or anything with a nicer UI and you can easily follow branch history.
- dchest 8y ago
  Nope. A branch in git is just a pointer to the tip of the branch: $ cat .git/refs/heads/master 170ec1365f9fc0ca281e72e6789d1df281d168ae From it, you can infer the commit history which gitk shows, but if you delete the branch (and discard the reflog), it's gone. In Fossil, each check-in (commit) actually records the name of the branch it belongs to: http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wi...
  - simcop2387 8y ago
    Don't even need to delete the branch, git reset <newcommit> will reset the branch to the given commit, throwing out whatever was there before. You may want to add --hard to that, depending on what you're doing.
  - mbell 8y ago
    Commits in git can have multiple parents, aka 'merge commits'. Using them maintains the branch history.
    - dchest 8y ago
      They don't maintain the branch name, or even the history of the branch: they just tell what are the parent commits of the commit; as mentioned above, this history can be a "lie". Fossil's history is immutable — once the commit is there, it's there forever (although you can prevent an artifact from being synched or displayed with "shunning").
      - mbell 8y ago
maltalex 8y ago
> Fossil stores content using an enduring file format in an SQLite database so that transactions are atomic even if interrupted by a power loss or system crash. Looks like the love is mutual
- loeg 8y ago
  Same principal author. Probably a source of bias.
  - jordsta 8y ago
    This is why I can't take any of this reasoning from SQLite seriously at all. The feeling I gather from this webpage is 'Hey, I made something I think is better than a popular thing, therefore every project I author from now on must use my thing and here are X number of refutable reasons why'
epage 8y ago
Under (1) > The principle maintainer of SQLite cannot function effectively without being able to view the successors of a check-in. I wish it went into more detail about why this is critical to his workflow.
- devnonymous 8y ago
  I'd be interested as well. Of all the reasons, this (not fit for intended purpose) struck me as the only compelling reason that doesn't come off as an 'and also...' argument (ie: justificatios/rationalisation of a decision, post making one's mind up). If I were to hazard a guess, this ability to follow descendents helps follow the evolution and intent of current state of code, given some previous state? (how did we get here from there and what else changed on the way). In git that'll kinda sorta be possible with git bisect.
  - matt_the_bass 8y ago
    ‘Gitk —all’ does this. Am I missing something?
- fulafel 8y ago
  It seems to be a very common case for Git users too. People often read "git log" or its tree/graph version. Or click on the "commits" tab in Github PRs / branches.
Animats 8y ago
Some time back, some GUI design firm asked on HN for a suggested open source program that needed a GUI developed. They had some developer time free and wanted something that would get them visibility. I suggested they do a GUI for Git. Several such things exists, but they're just buttons hooked up to the command line; they have no useful visual outputs. A good GUI for Git, where you could look at branches and such graphically, would get attention. Too hard, they said. They wanted something which just needed to be pretty, not something with tough human interface problems.
- Klathmon 8y ago
  I found myself using the "network" section of a work project on GitHub on an almost daily basis. It's basically a prettier git log. I know about git log (and the millions of options it has), but it's ugly as a sin, difficult to just quickly browse, and is just so busy that it's hard (for me at least) to quickly get information on if employee x merged branch y into z or if v has the latest commits from w, etc... So I ended up writing a user script to blow up the small window on the GitHub page to a larger size, and get rid of some stuff that we don't care about and made it a dashboard of sorts. I spent some time one day trying to find something like it, butcame up with pretty much nothing that was easily setup and maintained and that I didn't need to build my own application around.
  - JetSpiegel 8y ago
    Why not gitk? It is basically the same thing, but local. There is also gitg, which also includes primitive commit capabilities and uses the full-fat GNOME widgets, making it pretty.
    - Klathmon 8y ago
      Because both of them are basically "git log in a gui". It's the same overly busy UI, the same lack of easily seeable branch names (yes I know this isn't how git works internally, but it's extremely useful), the same vertical layout on our widescreen monitors, and they are still ugly to me (although this is honestly one of the lowest on my list of priorities). I'm looking for something like [0] but with a better UX (Github's version doesn't let you scroll with the mouse wheel for instance), is fast enough to pull up at a glance to quickly see the state of the whole repo, and won't get disabled if the repo has too many forks (and I'm guessing branches, although I've never seen it happen from then alone) like Github's does. It's easy to glance at and see where a branch is (what was merged into it, what it was merged into, etc...), who did the work (in the example it shows in a "tooltip" when you hover over the dot), roughly when the work was done, and what that branch includes. [0] https://imgur.com/tvTp5z8 https://imgur.com/tvTp5z8
cyberferret 8y ago
Sounds similar to my experiences with Bazaar many years ago. Ended up converting all project over to Git once we realised that nearly all external developers we worked with preferred Git and didn't have a clue about Bzr. Semi interesting full circle side note: One of those projects was actually a rudimentary version control system for a report writing app, which used SQLite as the VC data store.
- ropeadopepope 8y ago
  > Ended up converting all project over to Git once we realised that nearly all external developers we worked with preferred Git and didn't have a clue about Bzr. Why? There was a time not too long ago where this was true about git. Companies switched to git anyway.
  - danielvf 8y ago
    Git was so astonishingly better than SVN that most developers were instantly hooked. But when you know git and try bzr, it’s mostly the same thing but with different commands. Any gain is small and the pain is instant.
- raimue 8y ago
  I switched as well from bzr to git. The most important thing that Git offered over alternatives was amending commits to fix mistakes, reordering commits on the local branch with 'git rebase -i', and partial checkins with the staging area. Git was the first VCS I used which could commit unrelated changes separately with ease. With other tools, you manually have to copy changes around until the working copy only contains what you want to commit. Despite that, the Git command line interface is horribly inconsistent. Commands take separate words, `--options` or one-character flags without a scheme. Lots of synonyms such as staging area, index, or cache all meaning the same thing in the terminology does not help to make learning Git easier. For new users I would recommend Gitless, which tries to create a better interface to git and to solve the ambiguity in commands. As Gitless is a frontend to libgit2, it works with any git repository and you can also use normal git commands. The downside is that documentation usually only shows how to do stuff with 'git'. If you only learned 'gl', you have no idea how to reproduce it. http://gitless.com/ http://gitless.com/
disordinary 8y ago
I'm sick of being the go to person in my team to fix their git rebase problems.
avar 8y ago
I haven't used Fossil, but just a comment on some of that page, in the order they're presented: 1. It's unclear to me what he means. Yes git doesn't store anything like a doubly linked list of commits, and thus finding the "next" commit is more expensive, but you can do this with 'git log --reverse <commit>..', and it's really snappy on sqlite.git. It's much slower on larger repositories, but git could relatively easily grow the ability to maintain such a reverse index on the side to speed this up. 2. Yeah a lot of the index etc. is complex, but I wonder how something like "git add -p" works in Fossil. I assume not at all. Is there a way to incrementally "stage" merge conflicts? Much of that complexity comes with significant advantages. 3. This is complaining about two unrelated things. One is that GitHub by default isn't showing something like 'git log --graph' output, the other is that he's assuming that git treats the "master" branch magically. Yeah GitHub and other viewers could grow some ability to special-case the main branch and say "..and this was merged into 'master'" at the top of that page, but in any case all the same info exists in git as well, so it's just a complaint about a specific web UI.
- chx 8y ago
  As branch names are not recorded in commits, it is pretty much impossible to say what commit was next in a branch.
  - vlovich123 8y ago
    Have you looked at the --branches option for git log? It annotates which branch(es) a commit is part of unless you're talking about something else. There's obviously some cost but all this talk of "slow" is ignoring the fact that in practice on small repos (& yes - sqlite is small for git) you're not going to notice it. Also, you can limit your branches to those you're interested in to speed things up.
  - Macha 8y ago
    However, mercurial offers both named branches (hg branch) and pointer branches (hg bookmark) and when I last used it, it seemed the consensus was shifting to one of two positions, (a) just use hg bookmark or (b) use named branches for long lived branches only (master/default, develop, release branches etc) and bookmarks for feature branches/dev use.
AceJohnny2 8y ago
Paraphrasing: > 1. Git data model only lets you see ancestor commits, not descendants. Maintainer needs to find descendents. It's technically true about git's data model, but it's not too hard to reconstruct forward history based on all refs (branches for this purpose). (see "git rev-list"). They don't justify the use-case that demands this information be trivially available, and I've never personally needed it, so I find this a weak argument. I have needed to find what branches contained a given commit (either a regression or a bugfix), and that's available with "git branch --contains <SHA>" > 2. The mental model of git is complex (working dir, index, local head, local copy of remote head, remote head) Granted. It's especially always complicated trying to explain to beginners the distinction between local head, local copy of remote head, and remote head. Though it makes sense to me when working out technical implications of git's distributed data model, it's obvious that many users are overwhelmed. (I think the mental model is actually great, but I won't impose my opinion on others) > 3. Fossil's branch history display is better than GitHub's, and git doesn't tell you if a branch has been merged No mention of "git log --graph" (or any GUI alternative) which goes a long way of solving their complaint. I agree that GitHub's graphless history is frustrating, but that's a GitHub issue, not Git. However, Git does "swallow" merged branches, as the merge commit may be a property of the receiver branch, not the original branch (depending on your development model). Git doesn't enforce something there, so I agree with the issue. > 4. Git lacks essential wiki/bug-tracking. If you use 3rd-party tool for these, they're centralized Granted, though I'm not quite convinced in how "essential" it is to have that tightly integrated in the version control system, and thus have it distributed, but that's probably an artifact of me being used to existing git-based systems. A counterpoint to this is that Git (now) has a healthy ecosystem of alternatives for you to choose from. If you're not satisfied with Fossil's offering, how easy is it to change? > 5. Git requires administrative support for the extra web tools that Fossil otherwise integrates This follows from the previous point, so granted. I'd add to this that Git lacks a good access-control/code-review system, hence the rise of so many alternative portals (GitHub/Gitlab, Gerrit...) > 6. No-one really understands git [w/ XKCD link] Now you're just trolling. Overall, I'm surprised at how many points I actually agree with the author(s), but the main difference is that git purposefully aims at a more limited feature-set that excludes project-management (ie wiki/bugtracking), which I guess is the consequence of its Torvalds/kernel-originated development history.
profalseidol 8y ago
I always find myself writhing a bash script to commit-and-push-all with commit comment as arg. Especially for small projects.
gregoriol 8y ago
The argument that "Git lacks native wiki and bug tracking" is actually a very good thing: each of those 3 things (scm, wiki, bug tracking) are very different, and an scm must not bring a process/management system with it. Obviously, often it's nice to have all the things packaged, and GitLab does it amazingly well (maybe does too much these days though), but at a some level of process and IT management, wiki and issues have their tools already and should not depend on the scm.
- kazinator 8y ago
  I specifically want a version control system to be free of "wiki" and "bug tracking".
civilian 8y ago
> In contrast, Fossil users only need to think about their working directory and the check-in they are working on. That is 60% less distraction. Every developer has a finite number of brain-cycles. Fossil requires fewer brain-cycles to operate, thus freeing up intellectual resources to focus on the software under development. Not thinking about the actual remote head and/or the local copy of the remote head seems bad? I'm worried that Fossil is just obscure information, rather than presenting it. Is it possible to `fossil rebase origin/master` without an internet connection? // edit: Reading more of the docs, what I quoted at the top is definitely, ah, misleading. > When autosync is turned off, the changes you commit are only on your local repository. To share those changes with other repositories, do: fossil push URL > When you pull in changes from others, they go into your repository, not into your checked-out local tree. To get the changes into your local tree, use update: https://fossil-scm.org/index.html/doc/trunk/www/quickstart.wiki https://fossil-scm.org/index.html/doc/trunk/www/quickstart.w... We have confirmed that Fossil has The working directory The "index" or staging area The local head The local copy of the remote head The actual remote head So yeah, point #2 in the OP is lies.
locusm 8y ago
Anyone moved to BitKeeper now that its open source? http://www.bitkeeper.org http://www.bitkeeper.org
- kisstheblade 8y ago
  Probably not new users, or they shouldn't as the creator of BitKeeper says the project is dead and he is retired.
truantbuick 8y ago
First time I've heard of Fossil and started reading up on it: https://www.fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.wiki https://www.fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.w... In particular, I'm interested in the last section "4.2 Features found in Git but missing from Fossil". Maybe this is some deficiency of my workflow, but both those things make Fossil sound extremely unappealing to me. You're telling me I have to push all local changes every time I want to push anything? What if I was just debugging or experimenting with one branch, and then I had to switch to a "serious" branch to push some critical changes? And rebasing is fantastic when you have a feature branch workflow.
- sriku 8y ago
  A "default" user of fossil here - meaning all my personal projects are done with fossil .. only. I use git professionally (of course), but while I've used rebase to fit into workflows with github though I dislike the history garbling it does, I've never bothered with rebase with my fossil projects though I use feature branches. Just normal merges. I let it fork and merge at an appropriate point. (What I actually miss now and then is "git rerere" and a useful GUI like gtk.) Some notes on this choice focusing on the differences I actually use - 1. Fossil gives me peace of mind that I have everything (all code/notes/bugs/tags/branches) synced to the server with a single command "fossil sync". If you have autosync, then even better. I never get this peace of mind with git. 2. There're only two files to deal with - the fossil repo file and the fossil executable - which functions as the command line tool, a server for cloning and syncing, and minimal GUI. 3. I like the tagging system in fossil more. Since you can reuse tags unlike git, I just use a single "release" tag to mark code points pushed out .. with the commit containing details. I similarly use tags to mark points in the commit tree to revisit later (for example) - across branches. In fact, branches are just recurrent tags in fossil, so one less concept. 4. More peace of mind 'cos I can't leave a "dangling commit" that will be "garbage collected". Since I can't leave an unreachable commit, if I want to stash something, I just commit it with full notes, update to an earlier commit and "let it fork". (fossil does have stash, but I don't bother with it as .. less peace of mind). 5. I can customise the bug system for different uses.
- johnfound 8y ago
Myrmornis 8y ago
> The principle maintainer of SQLite cannot function effectively without being able to view the successors of a check-in. This one issue is sufficient reason to not use Git, in the view of the designer of SQLite. He's basically looking for git branch --contains $commit_or_branch isn't he? I do think it's a thoughtful write-up, hopefully git maintainers and github read it.
Bromskloss 8y ago
> Git lacks native wiki and bug tracking. If you want these essential features, you have to install additional software such as GitLab, or else use a third-party service such as GitHub. And even then, the wiki and bug reports are centralized, not distributed. Is a distributed bug reports etc even desirable? How would they work?
plastroltech 8y ago
Interesting and possibly relevant to note that SQLite is not your typical opensource project: "Open-Source, not Open-Contribution: SQLite is open-source, meaning that you can make as many copies of it as you want and do whatever you want with those copies, without limitation. But SQLite is not open-contribution. The project does not accept patches. Only 27 individuals have ever contributed any code to SQLite, and of those only 16 still have traces in the latest release. Only 3 developers have contributed non-comment changes within the previous five years and 96.4% of the latest release code was written by just two people. (The statistics in this paragraph were gathered on 2018-02-05.)" https://www.sqlite.org/copyright.html https://www.sqlite.org/copyright.html
- joshlemer 8y ago
  Do you know why they have this philosophy? Why would they not accept patches and pride themselves on having few contributors? Seems very odd.
  - lsaferite 8y ago
    Tight control? Consistent vision? Less overhead? All of the above?
  - Aissen 8y ago
    It's hinted in the linked page: > In order to keep SQLite completely free and unencumbered by copyright, the project does not accept patches. If you would like to make a suggested change, and include a patch as a proof-of-concept, that would be great. However please do not be offended if we rewrite your patch from scratch.
  - gmueckl 8y ago
    Because they can sell licenses that way and make money off the product.
  - SQLite 8y ago
    If we accept patches, then the person who has submitted the patch owns the copyright on that patch, and that means the software is no longer completely in the public domain. Unless, of course, the patch submitter has filled out a lot of legal paperwork to dedicate their code to the public domain, which rarely happens.
deathanatos 8y ago
> Given some historical check-in, it is quite challenging in Git to find out what came next. It can be done, but it is sufficiently difficult and slow that nobody ever does it. On the command line: git for-each-ref --contains <commit, branch, etc.> Lists all refs (branches, tags) that contain the passed argument. I'd be curious to know the author's need for this. I've used something similar on GitHub to determine when a given commit, typically a bugfix, is released. > There is no button in GitHub that shows the descendents of a check-in. There is: go to the commit's URL (https://github.com/$ORG/$PROJECT/commit/$COMMIT https://github.com/$ORG/$PROJECT/commit/$COMMIT) and below the subject & body of the commit, but above the author/commit time, there's a section that will have all branches, tags, and pull requests that the commit is a part of. For example: https://github.com/aio-libs/aiohttp/commit/d7f0511ead6d05cf6b7537c1b81f825e8f181ad7 https://github.com/aio-libs/aiohttp/commit/d7f0511ead6d05cf6... That commit is part of the "master" branch, and the "v3.1.2" tag.¹ ¹Note that more tags will likely appear in the future, if you're reading this comment some time from when I'm writing it.
jordigh 8y ago
"Nobody really understands git" is the truest part of that. While hyperbolic, it really has a lot of truth. It's always a bit frustrating when working with a team because everyone understands a different part of git and has slightly different ideas of how things should be done. I still routinely have to explain to others what a rebase is and others have to routinely explain to me what a blob really is. In a team of the most moderate size, teaching and learning git from each other is a regular task. People say git is simple underneath, and if you just learn its internal model, you can ignore its complex default UI. I disagree. Even just learning its internal model leads to surprises all the time, like the blobs that I keep forgetting why aren't they just called files.
- mabbo 8y ago
  The day I got over what I feel was the end of the steep part of the learning curve, everything made so much sense. Everything became easy to do. I've never been confused or unsure of what was going on in git since. What git needs is a chair lift up that hill. A way to easily get people there. But I have no idea what that would look like. Lots of people try, few do very well at it.
  - sammygutierrez 8y ago
    Git Pro's chapter on git internals does a good job of explaining some of the things going on under the hood. https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...
  - johnfn 8y ago
    The whole point about abstractions is you shouldn't need to understand the internals to use them. If the best defense of git is "once you understand the inner workings, it's so clear" then it is by definition a poor abstraction.
    - andrewflnr 8y ago
      Who said it's supposed to be an abstraction? The point, theoretically, of something like Git is that the actual unvarnished model is clear enough that you don't need an abstraction. The problem IMO is that the commands are kind of random and don't map cleanly to the model.
deleted 8y ago
[deleted]
nunez 8y ago
I thought git reflog shows you basically everything...
abqwe 8y ago
Also Fossil is licensed under 2-clause BSD license, Git - GNU GPL/LGPL v2/v2.1.
nineteen999 8y ago
I really like git these days, and I was initially stubborn, having grown up in the age of first cvs then svn. I design/implement core infrastructure and services for a large emergency services project. By nature the team that design and build it is especially conservative. It's only this past year I've been able to convince management that we should move to git because it offers advantages over the traditional tool (svn). What does make me chuckle however is seeing git used as a drop in replacement for svn without using any of the advanced branching/merging features it offers. I find it funny to hear a devops youngster eschewing the benefits of git after hearing that <n> hip opensource projects use it, just to find that they use using it with a single tree (or bunch thereof), just continually committing everything to the master branch. Just like people used to use cvs and svn.
deostroll 8y ago
Found the following line from the article... "entertaining" # begin quote Every developer has a finite number of "brain-cycles". Fossil requires "fewer brain-cycles to operate", thus "freeing up intellectual resources" to focus on the software under development. # end quote
igammarays 8y ago
Git is needlessly complex. Absolutely. The solution we've stumbled upon is to use a good GUI (GitKraken). Every developer I've introduced it to was at first intensely skeptical "I always use the command line and it's fine", but their mind was blown once they actually started using the GUI. Our whole team got a significant boost in productivity once we enforced the use of GitKraken, and now I fire it up even for the simplest of commands.
- TomK32 8y ago
  The only UI I've added to my toolchest in my 11 years of using git is [tig](https://jonas.github.io/tig/ https://jonas.github.io/tig/) and my default is to browse my repo with `tig --all` to see what everyone is up to.
- trextrex 8y ago
  I just attempted to try GitKraken, and while it looks quite good on paper, I find it perplexing (and a deal breaker) that it asks me to login (with Github or Gitkraken) before using the open source and free desktop client.
nurettin 8y ago
Unfortunately at work we use TFS which only offers Git and TFVS as version control systems.
deleted 8y ago
[deleted]
kadenshep 8y ago
>Every day humans make me again realize that I love my dogs, and respect my dogs, more than humans. There are exceptions but they are few and far between. You love them more than humans because they're fundamentally incapable of calling you out on your fud?
- luckydude 8y ago
  Dude, troll much? I'm retired, and you are messing with me? I engage because I want to help. BitKeeper is mostly dead, I've offered to go to facebook and transfer as much as I can to their SCM.
  - kadenshep 8y ago
    >Dude, troll much? How am I trolling? You just professed your love for nonsentient beings over actual people. >I'm retired What does this have to do with anything? >I engage because I want to help. I'm not sure what you think you're helping.
    - cookiecaper 8y ago
      I don't want to jump in out of turn here, but as a HN reader, I would ask that you please consider adjusting your tone. The only reason HN is worth anything is because you find the most interesting people here -- and love him or hate him, Larry McVoy has certainly earned a permanent spot. If you like git as much as you seem to like it, you should be thanking Larry, because my understanding is that it was his decision to play hardball with Linus that led to git's birth in the first place. If you disagree with him, the beautiful thing about HN is that you can state it politely, and you get the chance to talk to, and maybe even getting a little feedback from, a successful entrepreneur who sold source code management software to SV powerhouses for many years. There aren't a lot of people with that perspective. Be grateful that Larry is here and willing to share some of his knowledge and experience with you (that's what "I'm retired" means; he has no obligation to evangelize bitkeeper anymore, he is doing it for your information). Do NOT scare this type of person away from HN or make it too annoying for them to contribute. HN is nothing without such people. Seriously. So please put on your big boy pants and show some respect and professional decorum. This is a trade outlet, not reddit, and we try to maintain some respect and not to engage in snide attacks and petty accusations.
nimchimpsky 8y ago
I've been using it for years. I know next to nothing. Just commit, pull, push, merge. Works great, in big teams to.
ComputerGuru 8y ago
Speaking of large projects that haven’t moved to git, I wonder when WordPress is finally going to make the move?
8ig8 8y ago
Similar discussion from almost 8 years ago... https://news.ycombinator.com/item?id=1433387 https://news.ycombinator.com/item?id=1433387
greggman 8y ago
I am not qualified to judge whether Fossil is better than git and I can completely acknowledge that git has a step learning curve (although I feel that a big chunk of that learning curve is unlearning previous VCS experience). But, now that I do know git the biggest change from I noticed from previous VCSes is how much I work on multiple issues in the same repo. Something that was extremely hard with CVS, SVN, P4 (10yrs ago). A friend was struggling with git recently and ranting about it. He didn't get it and didn't understand why anyone would use it compared to what he was used to (non DVCS). I wrote him this analogy > Imagine some one was working with a flat file system, no folders. They somehow have been able to get work done for years. You come along and say “You should switch to this new hierarchical file system. It has folders and allows you to organize better”. And they’re like “WTF would I need folders for? I’ve been working just fine for years with a flat file system. I just want to get shit done. I don’t want to have to learn these crazy commands like cd and mkdir and rmdir. I don’t want to have to remember what folder I’m in and make sure I run commands in the correct folder. As it is things are simple. I type “rm filename” it gets deleted. Now I type “rm foldername” and I get an error. I then have to go read a manual on how to delete folders. I find out I can type “rmdir foldername” but I still get an error the folder is not empty. It’s effing making me insane. Why I can’t just do it like I’ve always done!”. And so it is with git. > One analogy with git is that a flat filesystem is 1 dimensional. A hierarchical file system is 2 dimensional. A filesystem with git is 3 dimensional. You switch in the 3rd dimension by changing branches with git checkout nameofbranch. If the branch does not exist yet (you want to create a new branch) then git checkout -b nameofnewbranch. > Git’s branches are effectively that 3rd dimension. They set your folder (and all folders below) to the state of the stuff committed to that branch. > What this enables is working on 5, 10, 20 things at once. Something I rarely did with cvs, svn, p4, or hg. Sure once in awhile I’d find some convoluted workflow to allow me to work on 2 things at once. Maybe they happened to be in totally unrelated parts of the code in which case it might not be too hard of I remembered to move the changed files for the other work before check in. Maybe I’d checkout the entire project in another folder so I'd have 2 or more copies of the project in separate folders on my hard drive. Or I’d backup all the files to another folder, checkout the latest, work on feature 2, check it back in, then copy my backedup folder back to my main work folder, and sync in the new changes or some other convoluted solution. > In git all that goes away. Because I have git style lightweight branches it becomes trivial to work on lots of different things and switch between them instantly. It’s that feature that I’d argue is the big difference. Look at most people’s local git repos and you’ll find they have 5, 10, 20 branches. One branch to work on bug ABC, another to work on bug DEF, another to update to docs, another to implement feature XYZ, another working on a longer term feature GHI, another to refactor the renderer, another to test out an experimental idea, etc. All of these branches are local to them only and have no effect on remote repos like github (unless they want them to). > If you’re used to not using git style lightweight branches and working on lots of things at once let me suggest it’s because all other VCSes suck in this area. You’ve been doing it so long that way you can’t even imagine it could be different. The same way in the hypothetical example above the guy with the flat filesystem can’t imagine why he’d ever need folders and is frustrated at having to remember what the current folder is, how to delete/rename a folder or how to move stuff between folders etc. All things he didn’t have to do with a flat system. > A big problem here is the word branch. Coming from cvs, svn, p4, and even hg the word "branch" means something heavy, something used to mark a release or a version. You probably rarely used them. I know I did. That's not what branches are in git. Branches in git are a fundamental part of the git workflow. If you're not using branches often you're probably missing out on what makes git different. > In other words, I expect you won’t get the point of git style branches. You’ve been living happily without them not knowing what you’re missing, content that you pretty much only ever work on one thing at a time or find convoluted workarounds in those rare cases you really have to. git removes all of that by making branching the normal thing to do and just like the person that’s used to a hierarchical file system could never go back to a flat file system, the person that’s used to git style branches and working on multiple things with ease would never go back to a VCS that’s only designed to work on one thing at a time which is pretty much all other systems. But, until you really get how freeing it is to be able to make lots of branches and work on multiple things you’ll keep doing it the old way and not realize what you’re missing. Which is basically way all anyone can really say is “stick it out and when you get it you’ll get it”. > Note: I get that p4 has some features for working on multiple things. I also get that hg added some extensions to work more like git. For hg in particular though, while they added after the fact optional features to make it more like git go through pretty much any hg tutorial and it won't teach you that workflow. It's not the norm AFAICT where as in git it is the norm. That difference in base is what really set the two apart. Sorry that was so long but my question for the Fossil guys would be "which workflow does Fossil encourage?" Lots of parallel development like git or like many other VCSes not so much parallel dev. Are branches light and easy like git or are they only meant for marking versions like the were in SVN, P4, CVS. Do branches even need to be related or can they be completely unrelated like gh-pages and the VCS won't complain that you're "off master" as hg does (did?)
jonahb 8y ago
Fossil vs. Git (2011): https://news.ycombinator.com/item?id=2524422 https://news.ycombinator.com/item?id=2524422
xdfil 8y ago
Git is Great! But Humans should never interact with it directly. Treat Git only as an API meant for applications to interact. If your team uses a common application to write their code which manages Git, it will align everyones method of use. It's funny watching an instructor training a group on Git. Everyone looks lost because there are too many scenarios being explained and how to handle them depending on what your intent might be. Before there is a solid grasp on the code management workflow the lecturing about commit comments begins, shifting clear over to the other side of the brain to guarantee none of it is collectively understood. Presenting too many options to the collective is counter-productive.
donut 8y ago
> Git encourages a style in which individual developers work in relative isolation, maintaining their own branches and occasionally rebasing and pushing selected changes up to the main repository. > Fossil, in contrast, strives to keep all changes from all contributors mirrored in the main repository (in separate branches) at all times. From https://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki https://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v...
alkonaut 8y ago
Git is absolutely terrible. Let’s just get that out of the way. But it ticks the two boxes - powerful enough (to e.g do proper merging, which cvs and svn never could) - tooling support, meaning it’s supported out of the box in bug trackers, build systems etc. All others (hg, perforce, svn, cvs, pijul, fossil, ...) fail one or both of the above. Now, I hope that one day git will be replaced by something nicer. But for the time being it’s what we’re stuck with. My pet peeve: sequential revision numbers. Why not have an arbitrary numbering of commits?? Saying “I have bug X in rev 1234 but it’s not in 1230” is fantastically powerful compared to “I have the bug in a1b34h but not in 3ae452”. These would be a sequence for a particular centralized branch - typically mainserver/master. Because this is the reality: it’s distributed version control but we almost all use centralized version control. This is also why it’s so odd that Git LFS took years to make it into git. Why would I want all past revisions of a binary (Yes, binaries must often be in version control, whether anyone thinks it’s a bad idea or not)?
- russdill 8y ago
  That's why most people tag their builds with git describe. It can easily tell you the most recent tag in the current branch and how many commits away from it the build is, for instance v1.5-15-a55325.
alkonaut 8y ago
These days I’m more interested in a comparison between pijul and git. Pijul actually brings real improvements over git.
_pmf_ 8y ago
Can someone explain how the problem of not being able to get successors causes issues in practice? I don't doubt it does, but I've never personally had a situation where inspecting the graph did not give the information I required in this regard.
FrozenVoid 8y ago
The only version management that i find intuitive is wiki model(i.e. wiki articles). Imagine 3 tasks. 1.Revert 3 git commits. This is one-click revert in wiki. 2.Diff 2 arbitrary commits. One-click in wiki. 3.change 2 lines of code. Edit->Submit in wiki. Why git has to be so arcane, especially reverting to specific point in time? The first code versioning control system that emulates the wikipedia UI model will win the market.
smarnach 8y ago
The list of reasons not to use Git seems as smug as it is uninformed. > With Git, it is very difficult to find the successors (decendents) of a check-in. "git log --children" and "git log --reverse" are very difficult indeed. > Fossil users only need to think about their working directory and the check-in they are working on. That is 60% less distraction. Since Fossil is a distributed version control system, there is also remote state to keep in mind. I don't know Fossil, so I don't know the details, but simply pretending the remote state does not exist seems at least misleading. > Setting up a website for a project to use Git requires a lot more software, and a lot more work, than setting up a similar site with an integrated package like Fossil. Setting up GitLab with Omnibus takes about five minutes. It's not Git itself, but rather a third-party package, but why should I care? (And in general, I wouldn't set up anything at all – I'd just use GitHub or GitLab or Bitbucket for my open-source software.) It's fine for different people to prefer different tools. Git can be annoying at times. However, it's a blessing that the open-source community is moving towards a standard everyone can work with, and Git is Good Enough to be that standard. Using an obscure alternative and justifying it with a list of downright wrong claims doesn't seem to create a welcoming atmosphere for new contributors. (And don't get me wrong – SQLite is a great piece of software, and I'm thankful people put in their time to create it.)
- smarnach 8y ago
  I just learned that SQLite doesn't accept any patches, so the argument that Git is the industry standard doesn't matter to them, and they just use what they prefer.
hi41 8y ago
Speaking truth to power! I like it! I so scared of saying that I never understood git and was getting by using only the most basic of the commands. Now Sqlite has called out!
skandl 8y ago
The refactored page brings up good points. Git has undeniably improved the world of software development, and is de facto the version control system to use in the majority of cases today. That said, that doesn't make the points SQLite makes invalid.

508 points by trextrex 8y ago

2, 4, 5, and 6 seem pretty weak. Not a particularly interesting article. Mostly comes down to 'we like X and Y about Fossil, and it works for us, so we use it instead'.

btgeekboy 8y ago
There’s certainly nothing wrong with that position though. If another tool fits their workflow better, then that’s what they should use.
arunc 8y ago
2,3,5: very valid and the reason why we use Mercurial instead. Can't afford to hire a Git guru in every team. Instead we use a tool that's easier for everyone.
- vangar 8y ago
  Once you start adding more than one developer to a Mercurial repo you need to know how Mercurial works, so I don't see how this is much different. In fact adding remotes to Mercurial was a much harder process last time I used it.
  - arunc 8y ago
    The point is, Mercurial is much easier learn. We are a team of 20 developers distributed across globe that transitioned from SVN and it was easy for us to pick up Mercurial and start using it within a couple of days. We tried git too and lost our changes inevitably. Our git knowledge is to be blamed but blame git CLI too! It is not easy to learn at all. After 12 years of git, I see articles with tips and guides on using git. That kind of hints how esoteric git CLI can be.
    - vangar 8y ago
      SmartGit is extremely useful, i'd recommend something like that instead of using the CLI if you have trouble.
    - zenhack 8y ago
      I feel like most of the trouble developers have with Git is pretty shallow, and it's a shame. It's not a tool I would want to get non-programmers to use (which may be a problem if you've got design folks on your team as well), but the model should be pretty learnable (in principle) to anyone who can manage to hobble their way through an intro data structures course. For folks like me, who spent their evenings in high-school screwing around with obscure linux distros and have been scouring badly written man pages trying to fix their computer for half their life, the little stuff is forgivable, and a lot of the big stuff is pretty good. But it's a shame how many inessential hurdles there are. See also: https://git-man-page-generator.lokaltog.net/ https://git-man-page-generator.lokaltog.net/ Biggest piece of advice for not losing data: learn about git-reflog and git-reset before doing anything that modifies history. Nothing is destroyed, even by "scary" operations like rebase, so it's always possible to recover something, but you need to know how to find stuff. I do some contract work for a university, where we have lots of student interns going through. We use GitHub, and we rarely rebase or cherry-pick, basically because while I could spend a bunch of time trying to teach git to new interns that will be gone in 4 months, It seems like a more efficient use of time to just occasionally put up with a messy history.

neals 8y ago

I'm a big fan of Fossil myself. But the SQlite people have something that I don't really have within the teams I operate : the authority to dare and speak out against Git and not be laughed away like a hipster that is just trying to be different.

matt_wulfeck 8y ago
Git is a use-case that is excellent for 90% of development. Sqlite is just an example where the use-case isn't necessarily ideal, not an indicator that it's "better" than git.
- bch 8y ago
  I’m a fossil fan. I’d say that git is fine for 90% of development (or some arbitrarily large number), but so is fossil. I don’t even think that SQLite-in-git would necessarily be a deal-breaker that couldn’t be worked around (drh ‘sqlite can chime in here). The whole space (from personal projects to global collaboration) is diverse enough that there’s no talking about “better” without qualifying the situation, either. Fossil is good for a large subset of work that can benefit from source control management, regardless of git. What git definately has is 1) scaleabilty, which is probably of no consequence for 99% of the cases it is employed 2) network effect, for better AND worse
  - nebulous1 8y ago
    > drh ‘sqlite can chime in here He already has > With Git, it is very difficult to find the successors (decendents) of a check-in ... This is a deal-breaker, a show-stopper.
    - deleted 8y ago
      [deleted]
    - AstralStorm 8y ago
      Someone still thinks in the single main branch mode. It is sometimes the main case but definitely not in git world. This operation is not easy in any DAG. It involves: - find all or desired branch tips - walk backwards until hitting tge desired checkin - memoize already seen parents to not walk them multiple times

crispyporkbites 8y ago

> Fossil and Git are both block-chain version-control systems Wow, we have gone full circle. Can’t wait for Linus to announce the git ICO!

roywiggins 8y ago
GitCoin
- tlrobinson 8y ago
  In fact "GitCoin" was one of the levels in Stripe's distributed systems CTF in 2014: https://github.com/ctfs/write-ups-2014/tree/master/stripe-ctf3/level1 https://github.com/ctfs/write-ups-2014/tree/master/stripe-ct...
- glitch003 8y ago
  >GitCoin Gitcoin is the name of a real blockchain project that let's people put ethereum bounties on their github issues. https://gitcoin.co/ https://gitcoin.co/ (Slightly off topic, sorry)
rwbt 8y ago
Technically Dr. Richard Hipp is right https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg26593.html https://www.mail-archive.com/fossil-users@lists.fossil-scm.o...
- jancsika 8y ago
  > So, why can't we rebrand fossil as Blockchain-VCS or something and move on toward world domination? Because Fossil-- like Git-- doesn't solve, attempt to solve, or even advertise itself as solving the problem of decentralized consensus. All existing blockchain technologies at least claim to be a solution to the problem of decentralized consensus. Therefore Dr. Richard Hipp is only "technically" right in the ways that do not matter, in the same way that I'm "technically" doing functional programming any time I write a javascript function. I assume he knows this and is being satirical.
- 8y ago

deedubaya 8y ago

I don't know anything about Fossil, but saying that no one understands Git just makes me think they're ignorant to learning Git. I doubt that's the case, but still, why say that?

crispyporkbites 8y ago
Because most users of git don’t really understand it. It’s really hard to learn properly and so most users just memorize the commands for their project’s workflow and ask the resident git expert to help (or nuke their local copy) when things go wrong.
- philwelch 8y ago
  It’s not hard to “really understand Git”. If anything, it’s the opposite problem—Git’s implementation is conceptually simple enough that the only good mental model the end user could possibly have is the implementation model. Systems like Subversion or Perforce or Fossil probably have even more complicated implementations than Git, and largely that’s to support a dumbed-down mental model that doesn’t require learning how the tool actually works. With Git, you learn how it works and you’re set, more or less.
  - ropeadopepope 8y ago
    > It’s not hard to “really understand Git”. Are you going to tell me you've never lost work because you didn't know git well enough to avoid putting your branch into a bad state?
    - philwelch 8y ago
      I’ve never lost work that I committed, which is the most you can ask of a version control system.
      - ropeadopepope 8y ago
        You've never botched a merge, try to undo it and accidentally lost work? It's happened to me and/or the people I work with roughly once a quarter since I started using git.

monocasa 8y ago

It's funny that they don't list the real reason, which is that Fossil is built on top of SQLite and they want to dogfood it.

rwbt 8y ago
SQLite is tested extensively fossil or not. Short of military software it's probably the most tested piece of software.
- monocasa 8y ago
  There are reasons to dogfood that aren't 'does it pass integration tests'. Stuff like 'is it to hard to use this feature in a real way', and 'performance bottlenecks that you might not have thought of'.
jopsen 8y ago
And the real reason to use git is that everybody else uses git.
- kadenshep 8y ago
  Everybody uses git because it's the most sane and powerful source control tool there is.
  - PowerRangError 8y ago
    Why do you think it's "the most" when there are equivalents? What does "most" mean? Most used was the point and the only salient quality that fits.
    - parvenu74 8y ago
      This is a great question. Where I work we use TFSVC and the VP of Engineering is willing to green-light a switch to Git as long as we can make a data-driven, objective case for why Git is better. In other words: "the devs prefer it" or "using Git makes me happier" don't wash as valid reasons. Branching in Git is certainly much easier but the counter that "you can branch with TFSVC too" is true, even if it's slower and eats up your hard drive space faster...

wiremine 8y ago

Good list, but I feel like they bury the lede: integrated wiki, issues, and notes. That doesn't scale to every project (linux kernel for example), but for a lot of projects it's really cool. Other selling points from the Fossil site: * Integrated Bug Tracking, Wiki, and Technotes * Built-in Web Interface _and_ Self-Contained (I combined these) * Simple Networking (no git://, just HTTP and SSH) * CGI/SCGI Enabled * Autosync - "Fossil supports "autosync" mode which helps to keep projects moving forward by reducing the amount of needless forking and merging often associated with distributed projects." * Robust & Reliable - "Fossil stores content using an enduring file format in an SQLite database so that transactions are atomic even if interrupted by a power loss or system crash. Automatic self-checks verify that all aspects of the repository are consistent prior to each commit." It would be easy to get into comparing git and Fossil feature by feature. That's interesting. But it's more interesting to compare the philosophies between the two tools. edit: for grammer.

syedkarim 8y ago
grammar
ccostes 8y ago
> But it's more interesting to compare the philosophies between the two tools. So what are their philosophies? Fossil is for small things and git is for scalability?
- shagie 8y ago
  Git is a filesystem ( https://git-scm.com/book/en/v2/Git-Internals-Git-Objects https://git-scm.com/book/en/v2/Git-Internals-Git-Objects ). > Git is a content-addressable filesystem. Great. What does that mean? It means that at the core of Git is a simple key-value data store. What this means is that you can insert any kind of content into a Git repository, for which Git will hand you back a unique key you can use later to retrieve that content. That's a great thing for matching the mindset of someone writing operating system software. Fossil is on top of a relational database... which is also a great thing for matching the mindset of someone writing a relational database.
8y ago

vangar 8y ago

"The mental model for Git is needlessly complex and consequently distracts attention from software under development. A user of Git needs to keep all of the following in mind: The working directory The "index" or staging area The local head The local copy of the remote head The actual remote head Git contains commands (or options on commands) for moving and comparing content between all of these locations. In contrast, Fossil users only need to think about their working directory and the check-in they are working on. That is 60% less distraction." I don't think about any of this when developing. I check out a branch, work on it, commit to it, and push it back up. If the fix is larger than a few commits i'll make a feature branch. What's so hard about that? Also, everyone using git isn't a bad thing. It means we finally have at least one standard in development.

wvenable 8y ago
I feel like everyone using git is like everyone using C.
- dimman 8y ago
  Fortunately for us C programmers then that not everyone has come to their senses.
psyc 8y ago
You get git. Good for you. A lot of smart people get git. A lot of smart people don't. I'm a smart person. I use git every day, 7 days a week. On my side projects, it's fine. Never a problem. At work, the workflow is more complicated, due to many branches, and many submodules. Submodules are a pain in practice. I think the mental model is too complex. This manifests as frequent unintended results, from simple operations that in my mind need not have unintended consequences. I never had any such problem with Perforce, even though I have used git twice as long. Your mileage obviously varies.
- kadenshep 8y ago
  >A lot of smart people don't. I'm sorry, I don't buy this at all. Git is one of the most simple source control tools there is. If you can't understand a DAG then there isn't much else you probably can understand in the development world. >This manifests as frequent unintended results No it doesn't. Every time I've seen people complain about "unintended results" it's literally been because of the above, and they've been complete morons so I'm never surprised when these people have "trouble" with git. You're building a graph, and you're doing pretty basic manipulation of that graph. >I never had any such problem with Perforce Uh what? Permission issues? Terrible branch performance? Merging between branches is basically a gamble -- it's actually insane how much this used to mess up over the most basic of merges. Having to "upgrade" the system? Ever done that. I'm going to guess no.

lifeisstillgood 8y ago

>>> The principle maintainer of SQLite cannot function effectively without being able to view the successors of a check-in. This one issue is sufficient reason to not use Git, in the view of the designer of SQLite Ok I'll bite. Why? I can see it's a nice idea - but at some point you add function X, then ten check ins modify that function. what's the difference between looking back at ten and looking forward at ten? Perhaps I need an example. If I remember rightly fossil was written by the Sqllite people? I tried it out for a while back in the day - I think it had this store the tickets in the branch alongside the code - it was an appealing idea, but got complicated quickly.

ozten 8y ago
Purely speculative, but I imagine you identify a bug that was introduced in commit X from 2 years ago. You want to answer, "Which supported releases of this product need to be patched?".
- tbodt 8y ago
  git tag --contains <commit> or git branch --contains <commit>
- aoeusnth1 8y ago
  isn't that just a question of looping over your release tags and asking whether each one can reach that commit? It's not too hard to script - I don't really see an advantage either way.

ccostes 8y ago

Interesting, I hadn't heard of Fossil before. It is useful to have a 'lingua franca' of open-source version control, but I'm not sure git is necessarily the best choice for that (not that network-effects usually result in the 'best' being chosen)

occams_chainsaw 8y ago

Git does not track branch history. This makes review of historical branches tedious. This isn't true. It's just the Fossil example has a better UI than their github example. Pop open gitk or anything with a nicer UI and you can easily follow branch history.

dchest 8y ago
Nope. A branch in git is just a pointer to the tip of the branch: $ cat .git/refs/heads/master 170ec1365f9fc0ca281e72e6789d1df281d168ae From it, you can infer the commit history which gitk shows, but if you delete the branch (and discard the reflog), it's gone. In Fossil, each check-in (commit) actually records the name of the branch it belongs to: http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wi...
- simcop2387 8y ago
  Don't even need to delete the branch, git reset <newcommit> will reset the branch to the given commit, throwing out whatever was there before. You may want to add --hard to that, depending on what you're doing.
- mbell 8y ago
  Commits in git can have multiple parents, aka 'merge commits'. Using them maintains the branch history.
  - dchest 8y ago
    They don't maintain the branch name, or even the history of the branch: they just tell what are the parent commits of the commit; as mentioned above, this history can be a "lie". Fossil's history is immutable — once the commit is there, it's there forever (although you can prevent an artifact from being synched or displayed with "shunning").
    - mbell 8y ago

maltalex 8y ago

> Fossil stores content using an enduring file format in an SQLite database so that transactions are atomic even if interrupted by a power loss or system crash. Looks like the love is mutual

loeg 8y ago
Same principal author. Probably a source of bias.
- jordsta 8y ago
  This is why I can't take any of this reasoning from SQLite seriously at all. The feeling I gather from this webpage is 'Hey, I made something I think is better than a popular thing, therefore every project I author from now on must use my thing and here are X number of refutable reasons why'

epage 8y ago

Under (1) > The principle maintainer of SQLite cannot function effectively without being able to view the successors of a check-in. I wish it went into more detail about why this is critical to his workflow.

devnonymous 8y ago
I'd be interested as well. Of all the reasons, this (not fit for intended purpose) struck me as the only compelling reason that doesn't come off as an 'and also...' argument (ie: justificatios/rationalisation of a decision, post making one's mind up). If I were to hazard a guess, this ability to follow descendents helps follow the evolution and intent of current state of code, given some previous state? (how did we get here from there and what else changed on the way). In git that'll kinda sorta be possible with git bisect.
- matt_the_bass 8y ago
  ‘Gitk —all’ does this. Am I missing something?
fulafel 8y ago
It seems to be a very common case for Git users too. People often read "git log" or its tree/graph version. Or click on the "commits" tab in Github PRs / branches.

Animats 8y ago

Some time back, some GUI design firm asked on HN for a suggested open source program that needed a GUI developed. They had some developer time free and wanted something that would get them visibility. I suggested they do a GUI for Git. Several such things exists, but they're just buttons hooked up to the command line; they have no useful visual outputs. A good GUI for Git, where you could look at branches and such graphically, would get attention. Too hard, they said. They wanted something which just needed to be pretty, not something with tough human interface problems.

Klathmon 8y ago
I found myself using the "network" section of a work project on GitHub on an almost daily basis. It's basically a prettier git log. I know about git log (and the millions of options it has), but it's ugly as a sin, difficult to just quickly browse, and is just so busy that it's hard (for me at least) to quickly get information on if employee x merged branch y into z or if v has the latest commits from w, etc... So I ended up writing a user script to blow up the small window on the GitHub page to a larger size, and get rid of some stuff that we don't care about and made it a dashboard of sorts. I spent some time one day trying to find something like it, butcame up with pretty much nothing that was easily setup and maintained and that I didn't need to build my own application around.
- JetSpiegel 8y ago
  Why not gitk? It is basically the same thing, but local. There is also gitg, which also includes primitive commit capabilities and uses the full-fat GNOME widgets, making it pretty.
  - Klathmon 8y ago
    Because both of them are basically "git log in a gui". It's the same overly busy UI, the same lack of easily seeable branch names (yes I know this isn't how git works internally, but it's extremely useful), the same vertical layout on our widescreen monitors, and they are still ugly to me (although this is honestly one of the lowest on my list of priorities). I'm looking for something like [0] but with a better UX (Github's version doesn't let you scroll with the mouse wheel for instance), is fast enough to pull up at a glance to quickly see the state of the whole repo, and won't get disabled if the repo has too many forks (and I'm guessing branches, although I've never seen it happen from then alone) like Github's does. It's easy to glance at and see where a branch is (what was merged into it, what it was merged into, etc...), who did the work (in the example it shows in a "tooltip" when you hover over the dot), roughly when the work was done, and what that branch includes. [0] https://imgur.com/tvTp5z8 https://imgur.com/tvTp5z8

cyberferret 8y ago

Sounds similar to my experiences with Bazaar many years ago. Ended up converting all project over to Git once we realised that nearly all external developers we worked with preferred Git and didn't have a clue about Bzr. Semi interesting full circle side note: One of those projects was actually a rudimentary version control system for a report writing app, which used SQLite as the VC data store.

ropeadopepope 8y ago
> Ended up converting all project over to Git once we realised that nearly all external developers we worked with preferred Git and didn't have a clue about Bzr. Why? There was a time not too long ago where this was true about git. Companies switched to git anyway.
- danielvf 8y ago
  Git was so astonishingly better than SVN that most developers were instantly hooked. But when you know git and try bzr, it’s mostly the same thing but with different commands. Any gain is small and the pain is instant.
raimue 8y ago
I switched as well from bzr to git. The most important thing that Git offered over alternatives was amending commits to fix mistakes, reordering commits on the local branch with 'git rebase -i', and partial checkins with the staging area. Git was the first VCS I used which could commit unrelated changes separately with ease. With other tools, you manually have to copy changes around until the working copy only contains what you want to commit. Despite that, the Git command line interface is horribly inconsistent. Commands take separate words, `--options` or one-character flags without a scheme. Lots of synonyms such as staging area, index, or cache all meaning the same thing in the terminology does not help to make learning Git easier. For new users I would recommend Gitless, which tries to create a better interface to git and to solve the ambiguity in commands. As Gitless is a frontend to libgit2, it works with any git repository and you can also use normal git commands. The downside is that documentation usually only shows how to do stuff with 'git'. If you only learned 'gl', you have no idea how to reproduce it. http://gitless.com/ http://gitless.com/

disordinary 8y ago

I'm sick of being the go to person in my team to fix their git rebase problems.

avar 8y ago

I haven't used Fossil, but just a comment on some of that page, in the order they're presented: 1. It's unclear to me what he means. Yes git doesn't store anything like a doubly linked list of commits, and thus finding the "next" commit is more expensive, but you can do this with 'git log --reverse <commit>..', and it's really snappy on sqlite.git. It's much slower on larger repositories, but git could relatively easily grow the ability to maintain such a reverse index on the side to speed this up. 2. Yeah a lot of the index etc. is complex, but I wonder how something like "git add -p" works in Fossil. I assume not at all. Is there a way to incrementally "stage" merge conflicts? Much of that complexity comes with significant advantages. 3. This is complaining about two unrelated things. One is that GitHub by default isn't showing something like 'git log --graph' output, the other is that he's assuming that git treats the "master" branch magically. Yeah GitHub and other viewers could grow some ability to special-case the main branch and say "..and this was merged into 'master'" at the top of that page, but in any case all the same info exists in git as well, so it's just a complaint about a specific web UI.

chx 8y ago
As branch names are not recorded in commits, it is pretty much impossible to say what commit was next in a branch.
- vlovich123 8y ago
  Have you looked at the --branches option for git log? It annotates which branch(es) a commit is part of unless you're talking about something else. There's obviously some cost but all this talk of "slow" is ignoring the fact that in practice on small repos (& yes - sqlite is small for git) you're not going to notice it. Also, you can limit your branches to those you're interested in to speed things up.
- Macha 8y ago
  However, mercurial offers both named branches (hg branch) and pointer branches (hg bookmark) and when I last used it, it seemed the consensus was shifting to one of two positions, (a) just use hg bookmark or (b) use named branches for long lived branches only (master/default, develop, release branches etc) and bookmarks for feature branches/dev use.

AceJohnny2 8y ago

Paraphrasing: > 1. Git data model only lets you see ancestor commits, not descendants. Maintainer needs to find descendents. It's technically true about git's data model, but it's not too hard to reconstruct forward history based on all refs (branches for this purpose). (see "git rev-list"). They don't justify the use-case that demands this information be trivially available, and I've never personally needed it, so I find this a weak argument. I have needed to find what branches contained a given commit (either a regression or a bugfix), and that's available with "git branch --contains <SHA>" > 2. The mental model of git is complex (working dir, index, local head, local copy of remote head, remote head) Granted. It's especially always complicated trying to explain to beginners the distinction between local head, local copy of remote head, and remote head. Though it makes sense to me when working out technical implications of git's distributed data model, it's obvious that many users are overwhelmed. (I think the mental model is actually great, but I won't impose my opinion on others) > 3. Fossil's branch history display is better than GitHub's, and git doesn't tell you if a branch has been merged No mention of "git log --graph" (or any GUI alternative) which goes a long way of solving their complaint. I agree that GitHub's graphless history is frustrating, but that's a GitHub issue, not Git. However, Git does "swallow" merged branches, as the merge commit may be a property of the receiver branch, not the original branch (depending on your development model). Git doesn't enforce something there, so I agree with the issue. > 4. Git lacks essential wiki/bug-tracking. If you use 3rd-party tool for these, they're centralized Granted, though I'm not quite convinced in how "essential" it is to have that tightly integrated in the version control system, and thus have it distributed, but that's probably an artifact of me being used to existing git-based systems. A counterpoint to this is that Git (now) has a healthy ecosystem of alternatives for you to choose from. If you're not satisfied with Fossil's offering, how easy is it to change? > 5. Git requires administrative support for the extra web tools that Fossil otherwise integrates This follows from the previous point, so granted. I'd add to this that Git lacks a good access-control/code-review system, hence the rise of so many alternative portals (GitHub/Gitlab, Gerrit...) > 6. No-one really understands git [w/ XKCD link] Now you're just trolling. Overall, I'm surprised at how many points I actually agree with the author(s), but the main difference is that git purposefully aims at a more limited feature-set that excludes project-management (ie wiki/bugtracking), which I guess is the consequence of its Torvalds/kernel-originated development history.

profalseidol 8y ago

I always find myself writhing a bash script to commit-and-push-all with commit comment as arg. Especially for small projects.

gregoriol 8y ago

The argument that "Git lacks native wiki and bug tracking" is actually a very good thing: each of those 3 things (scm, wiki, bug tracking) are very different, and an scm must not bring a process/management system with it. Obviously, often it's nice to have all the things packaged, and GitLab does it amazingly well (maybe does too much these days though), but at a some level of process and IT management, wiki and issues have their tools already and should not depend on the scm.

kazinator 8y ago
I specifically want a version control system to be free of "wiki" and "bug tracking".

civilian 8y ago

> In contrast, Fossil users only need to think about their working directory and the check-in they are working on. That is 60% less distraction. Every developer has a finite number of brain-cycles. Fossil requires fewer brain-cycles to operate, thus freeing up intellectual resources to focus on the software under development. Not thinking about the actual remote head and/or the local copy of the remote head seems bad? I'm worried that Fossil is just obscure information, rather than presenting it. Is it possible to `fossil rebase origin/master` without an internet connection? // edit: Reading more of the docs, what I quoted at the top is definitely, ah, misleading. > When autosync is turned off, the changes you commit are only on your local repository. To share those changes with other repositories, do: fossil push URL > When you pull in changes from others, they go into your repository, not into your checked-out local tree. To get the changes into your local tree, use update: https://fossil-scm.org/index.html/doc/trunk/www/quickstart.wiki https://fossil-scm.org/index.html/doc/trunk/www/quickstart.w... We have confirmed that Fossil has The working directory The "index" or staging area The local head The local copy of the remote head The actual remote head So yeah, point #2 in the OP is lies.

locusm 8y ago

Anyone moved to BitKeeper now that its open source? http://www.bitkeeper.org http://www.bitkeeper.org

kisstheblade 8y ago
Probably not new users, or they shouldn't as the creator of BitKeeper says the project is dead and he is retired.

truantbuick 8y ago

First time I've heard of Fossil and started reading up on it: https://www.fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.wiki https://www.fossil-scm.org/xfer/doc/trunk/www/fossil-v-git.w... In particular, I'm interested in the last section "4.2 Features found in Git but missing from Fossil". Maybe this is some deficiency of my workflow, but both those things make Fossil sound extremely unappealing to me. You're telling me I have to push all local changes every time I want to push anything? What if I was just debugging or experimenting with one branch, and then I had to switch to a "serious" branch to push some critical changes? And rebasing is fantastic when you have a feature branch workflow.

sriku 8y ago
A "default" user of fossil here - meaning all my personal projects are done with fossil .. only. I use git professionally (of course), but while I've used rebase to fit into workflows with github though I dislike the history garbling it does, I've never bothered with rebase with my fossil projects though I use feature branches. Just normal merges. I let it fork and merge at an appropriate point. (What I actually miss now and then is "git rerere" and a useful GUI like gtk.) Some notes on this choice focusing on the differences I actually use - 1. Fossil gives me peace of mind that I have everything (all code/notes/bugs/tags/branches) synced to the server with a single command "fossil sync". If you have autosync, then even better. I never get this peace of mind with git. 2. There're only two files to deal with - the fossil repo file and the fossil executable - which functions as the command line tool, a server for cloning and syncing, and minimal GUI. 3. I like the tagging system in fossil more. Since you can reuse tags unlike git, I just use a single "release" tag to mark code points pushed out .. with the commit containing details. I similarly use tags to mark points in the commit tree to revisit later (for example) - across branches. In fact, branches are just recurrent tags in fossil, so one less concept. 4. More peace of mind 'cos I can't leave a "dangling commit" that will be "garbage collected". Since I can't leave an unreachable commit, if I want to stash something, I just commit it with full notes, update to an earlier commit and "let it fork". (fossil does have stash, but I don't bother with it as .. less peace of mind). 5. I can customise the bug system for different uses.
johnfound 8y ago

Myrmornis 8y ago

> The principle maintainer of SQLite cannot function effectively without being able to view the successors of a check-in. This one issue is sufficient reason to not use Git, in the view of the designer of SQLite. He's basically looking for git branch --contains $commit_or_branch isn't he? I do think it's a thoughtful write-up, hopefully git maintainers and github read it.

Bromskloss 8y ago

> Git lacks native wiki and bug tracking. If you want these essential features, you have to install additional software such as GitLab, or else use a third-party service such as GitHub. And even then, the wiki and bug reports are centralized, not distributed. Is a distributed bug reports etc even desirable? How would they work?

plastroltech 8y ago

Interesting and possibly relevant to note that SQLite is not your typical opensource project: "Open-Source, not Open-Contribution: SQLite is open-source, meaning that you can make as many copies of it as you want and do whatever you want with those copies, without limitation. But SQLite is not open-contribution. The project does not accept patches. Only 27 individuals have ever contributed any code to SQLite, and of those only 16 still have traces in the latest release. Only 3 developers have contributed non-comment changes within the previous five years and 96.4% of the latest release code was written by just two people. (The statistics in this paragraph were gathered on 2018-02-05.)" https://www.sqlite.org/copyright.html https://www.sqlite.org/copyright.html

joshlemer 8y ago
Do you know why they have this philosophy? Why would they not accept patches and pride themselves on having few contributors? Seems very odd.
- lsaferite 8y ago
  Tight control? Consistent vision? Less overhead? All of the above?
- Aissen 8y ago
  It's hinted in the linked page: > In order to keep SQLite completely free and unencumbered by copyright, the project does not accept patches. If you would like to make a suggested change, and include a patch as a proof-of-concept, that would be great. However please do not be offended if we rewrite your patch from scratch.
- gmueckl 8y ago
  Because they can sell licenses that way and make money off the product.
- SQLite 8y ago
  If we accept patches, then the person who has submitted the patch owns the copyright on that patch, and that means the software is no longer completely in the public domain. Unless, of course, the patch submitter has filled out a lot of legal paperwork to dedicate their code to the public domain, which rarely happens.

deathanatos 8y ago

> Given some historical check-in, it is quite challenging in Git to find out what came next. It can be done, but it is sufficiently difficult and slow that nobody ever does it. On the command line: git for-each-ref --contains <commit, branch, etc.> Lists all refs (branches, tags) that contain the passed argument. I'd be curious to know the author's need for this. I've used something similar on GitHub to determine when a given commit, typically a bugfix, is released. > There is no button in GitHub that shows the descendents of a check-in. There is: go to the commit's URL (https://github.com/$ORG/$PROJECT/commit/$COMMIT https://github.com/$ORG/$PROJECT/commit/$COMMIT) and below the subject & body of the commit, but above the author/commit time, there's a section that will have all branches, tags, and pull requests that the commit is a part of. For example: https://github.com/aio-libs/aiohttp/commit/d7f0511ead6d05cf6b7537c1b81f825e8f181ad7 https://github.com/aio-libs/aiohttp/commit/d7f0511ead6d05cf6... That commit is part of the "master" branch, and the "v3.1.2" tag.¹ ¹Note that more tags will likely appear in the future, if you're reading this comment some time from when I'm writing it.

jordigh 8y ago

"Nobody really understands git" is the truest part of that. While hyperbolic, it really has a lot of truth. It's always a bit frustrating when working with a team because everyone understands a different part of git and has slightly different ideas of how things should be done. I still routinely have to explain to others what a rebase is and others have to routinely explain to me what a blob really is. In a team of the most moderate size, teaching and learning git from each other is a regular task. People say git is simple underneath, and if you just learn its internal model, you can ignore its complex default UI. I disagree. Even just learning its internal model leads to surprises all the time, like the blobs that I keep forgetting why aren't they just called files.

mabbo 8y ago
The day I got over what I feel was the end of the steep part of the learning curve, everything made so much sense. Everything became easy to do. I've never been confused or unsure of what was going on in git since. What git needs is a chair lift up that hill. A way to easily get people there. But I have no idea what that would look like. Lots of people try, few do very well at it.
- sammygutierrez 8y ago
  Git Pro's chapter on git internals does a good job of explaining some of the things going on under the hood. https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Po...
- johnfn 8y ago
  The whole point about abstractions is you shouldn't need to understand the internals to use them. If the best defense of git is "once you understand the inner workings, it's so clear" then it is by definition a poor abstraction.
  - andrewflnr 8y ago
    Who said it's supposed to be an abstraction? The point, theoretically, of something like Git is that the actual unvarnished model is clear enough that you don't need an abstraction. The problem IMO is that the commands are kind of random and don't map cleanly to the model.

deleted 8y ago

[deleted]

nunez 8y ago

I thought git reflog shows you basically everything...

abqwe 8y ago

Also Fossil is licensed under 2-clause BSD license, Git - GNU GPL/LGPL v2/v2.1.

nineteen999 8y ago

I really like git these days, and I was initially stubborn, having grown up in the age of first cvs then svn. I design/implement core infrastructure and services for a large emergency services project. By nature the team that design and build it is especially conservative. It's only this past year I've been able to convince management that we should move to git because it offers advantages over the traditional tool (svn). What does make me chuckle however is seeing git used as a drop in replacement for svn without using any of the advanced branching/merging features it offers. I find it funny to hear a devops youngster eschewing the benefits of git after hearing that <n> hip opensource projects use it, just to find that they use using it with a single tree (or bunch thereof), just continually committing everything to the master branch. Just like people used to use cvs and svn.

deostroll 8y ago

Found the following line from the article... "entertaining" # begin quote Every developer has a finite number of "brain-cycles". Fossil requires "fewer brain-cycles to operate", thus "freeing up intellectual resources" to focus on the software under development. # end quote

igammarays 8y ago

Git is needlessly complex. Absolutely. The solution we've stumbled upon is to use a good GUI (GitKraken). Every developer I've introduced it to was at first intensely skeptical "I always use the command line and it's fine", but their mind was blown once they actually started using the GUI. Our whole team got a significant boost in productivity once we enforced the use of GitKraken, and now I fire it up even for the simplest of commands.

TomK32 8y ago
The only UI I've added to my toolchest in my 11 years of using git is [tig](https://jonas.github.io/tig/ https://jonas.github.io/tig/) and my default is to browse my repo with `tig --all` to see what everyone is up to.
trextrex 8y ago
I just attempted to try GitKraken, and while it looks quite good on paper, I find it perplexing (and a deal breaker) that it asks me to login (with Github or Gitkraken) before using the open source and free desktop client.

nurettin 8y ago

Unfortunately at work we use TFS which only offers Git and TFVS as version control systems.

deleted 8y ago

[deleted]

kadenshep 8y ago

>Every day humans make me again realize that I love my dogs, and respect my dogs, more than humans. There are exceptions but they are few and far between. You love them more than humans because they're fundamentally incapable of calling you out on your fud?

luckydude 8y ago
Dude, troll much? I'm retired, and you are messing with me? I engage because I want to help. BitKeeper is mostly dead, I've offered to go to facebook and transfer as much as I can to their SCM.
- kadenshep 8y ago
  >Dude, troll much? How am I trolling? You just professed your love for nonsentient beings over actual people. >I'm retired What does this have to do with anything? >I engage because I want to help. I'm not sure what you think you're helping.
  - cookiecaper 8y ago
    I don't want to jump in out of turn here, but as a HN reader, I would ask that you please consider adjusting your tone. The only reason HN is worth anything is because you find the most interesting people here -- and love him or hate him, Larry McVoy has certainly earned a permanent spot. If you like git as much as you seem to like it, you should be thanking Larry, because my understanding is that it was his decision to play hardball with Linus that led to git's birth in the first place. If you disagree with him, the beautiful thing about HN is that you can state it politely, and you get the chance to talk to, and maybe even getting a little feedback from, a successful entrepreneur who sold source code management software to SV powerhouses for many years. There aren't a lot of people with that perspective. Be grateful that Larry is here and willing to share some of his knowledge and experience with you (that's what "I'm retired" means; he has no obligation to evangelize bitkeeper anymore, he is doing it for your information). Do NOT scare this type of person away from HN or make it too annoying for them to contribute. HN is nothing without such people. Seriously. So please put on your big boy pants and show some respect and professional decorum. This is a trade outlet, not reddit, and we try to maintain some respect and not to engage in snide attacks and petty accusations.

nimchimpsky 8y ago

I've been using it for years. I know next to nothing. Just commit, pull, push, merge. Works great, in big teams to.

ComputerGuru 8y ago

Speaking of large projects that haven’t moved to git, I wonder when WordPress is finally going to make the move?

8ig8 8y ago

Similar discussion from almost 8 years ago... https://news.ycombinator.com/item?id=1433387 https://news.ycombinator.com/item?id=1433387

greggman 8y ago

I am not qualified to judge whether Fossil is better than git and I can completely acknowledge that git has a step learning curve (although I feel that a big chunk of that learning curve is unlearning previous VCS experience). But, now that I do know git the biggest change from I noticed from previous VCSes is how much I work on multiple issues in the same repo. Something that was extremely hard with CVS, SVN, P4 (10yrs ago). A friend was struggling with git recently and ranting about it. He didn't get it and didn't understand why anyone would use it compared to what he was used to (non DVCS). I wrote him this analogy > Imagine some one was working with a flat file system, no folders. They somehow have been able to get work done for years. You come along and say “You should switch to this new hierarchical file system. It has folders and allows you to organize better”. And they’re like “WTF would I need folders for? I’ve been working just fine for years with a flat file system. I just want to get shit done. I don’t want to have to learn these crazy commands like cd and mkdir and rmdir. I don’t want to have to remember what folder I’m in and make sure I run commands in the correct folder. As it is things are simple. I type “rm filename” it gets deleted. Now I type “rm foldername” and I get an error. I then have to go read a manual on how to delete folders. I find out I can type “rmdir foldername” but I still get an error the folder is not empty. It’s effing making me insane. Why I can’t just do it like I’ve always done!”. And so it is with git. > One analogy with git is that a flat filesystem is 1 dimensional. A hierarchical file system is 2 dimensional. A filesystem with git is 3 dimensional. You switch in the 3rd dimension by changing branches with git checkout nameofbranch. If the branch does not exist yet (you want to create a new branch) then git checkout -b nameofnewbranch. > Git’s branches are effectively that 3rd dimension. They set your folder (and all folders below) to the state of the stuff committed to that branch. > What this enables is working on 5, 10, 20 things at once. Something I rarely did with cvs, svn, p4, or hg. Sure once in awhile I’d find some convoluted workflow to allow me to work on 2 things at once. Maybe they happened to be in totally unrelated parts of the code in which case it might not be too hard of I remembered to move the changed files for the other work before check in. Maybe I’d checkout the entire project in another folder so I'd have 2 or more copies of the project in separate folders on my hard drive. Or I’d backup all the files to another folder, checkout the latest, work on feature 2, check it back in, then copy my backedup folder back to my main work folder, and sync in the new changes or some other convoluted solution. > In git all that goes away. Because I have git style lightweight branches it becomes trivial to work on lots of different things and switch between them instantly. It’s that feature that I’d argue is the big difference. Look at most people’s local git repos and you’ll find they have 5, 10, 20 branches. One branch to work on bug ABC, another to work on bug DEF, another to update to docs, another to implement feature XYZ, another working on a longer term feature GHI, another to refactor the renderer, another to test out an experimental idea, etc. All of these branches are local to them only and have no effect on remote repos like github (unless they want them to). > If you’re used to not using git style lightweight branches and working on lots of things at once let me suggest it’s because all other VCSes suck in this area. You’ve been doing it so long that way you can’t even imagine it could be different. The same way in the hypothetical example above the guy with the flat filesystem can’t imagine why he’d ever need folders and is frustrated at having to remember what the current folder is, how to delete/rename a folder or how to move stuff between folders etc. All things he didn’t have to do with a flat system. > A big problem here is the word branch. Coming from cvs, svn, p4, and even hg the word "branch" means something heavy, something used to mark a release or a version. You probably rarely used them. I know I did. That's not what branches are in git. Branches in git are a fundamental part of the git workflow. If you're not using branches often you're probably missing out on what makes git different. > In other words, I expect you won’t get the point of git style branches. You’ve been living happily without them not knowing what you’re missing, content that you pretty much only ever work on one thing at a time or find convoluted workarounds in those rare cases you really have to. git removes all of that by making branching the normal thing to do and just like the person that’s used to a hierarchical file system could never go back to a flat file system, the person that’s used to git style branches and working on multiple things with ease would never go back to a VCS that’s only designed to work on one thing at a time which is pretty much all other systems. But, until you really get how freeing it is to be able to make lots of branches and work on multiple things you’ll keep doing it the old way and not realize what you’re missing. Which is basically way all anyone can really say is “stick it out and when you get it you’ll get it”. > Note: I get that p4 has some features for working on multiple things. I also get that hg added some extensions to work more like git. For hg in particular though, while they added after the fact optional features to make it more like git go through pretty much any hg tutorial and it won't teach you that workflow. It's not the norm AFAICT where as in git it is the norm. That difference in base is what really set the two apart. Sorry that was so long but my question for the Fossil guys would be "which workflow does Fossil encourage?" Lots of parallel development like git or like many other VCSes not so much parallel dev. Are branches light and easy like git or are they only meant for marking versions like the were in SVN, P4, CVS. Do branches even need to be related or can they be completely unrelated like gh-pages and the VCS won't complain that you're "off master" as hg does (did?)

jonahb 8y ago

Fossil vs. Git (2011): https://news.ycombinator.com/item?id=2524422 https://news.ycombinator.com/item?id=2524422

xdfil 8y ago

Git is Great! But Humans should never interact with it directly. Treat Git only as an API meant for applications to interact. If your team uses a common application to write their code which manages Git, it will align everyones method of use. It's funny watching an instructor training a group on Git. Everyone looks lost because there are too many scenarios being explained and how to handle them depending on what your intent might be. Before there is a solid grasp on the code management workflow the lecturing about commit comments begins, shifting clear over to the other side of the brain to guarantee none of it is collectively understood. Presenting too many options to the collective is counter-productive.

donut 8y ago

> Git encourages a style in which individual developers work in relative isolation, maintaining their own branches and occasionally rebasing and pushing selected changes up to the main repository. > Fossil, in contrast, strives to keep all changes from all contributors mirrored in the main repository (in separate branches) at all times. From https://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v-git.wiki https://www.fossil-scm.org/index.html/doc/trunk/www/fossil-v...

alkonaut 8y ago

Git is absolutely terrible. Let’s just get that out of the way. But it ticks the two boxes - powerful enough (to e.g do proper merging, which cvs and svn never could) - tooling support, meaning it’s supported out of the box in bug trackers, build systems etc. All others (hg, perforce, svn, cvs, pijul, fossil, ...) fail one or both of the above. Now, I hope that one day git will be replaced by something nicer. But for the time being it’s what we’re stuck with. My pet peeve: sequential revision numbers. Why not have an arbitrary numbering of commits?? Saying “I have bug X in rev 1234 but it’s not in 1230” is fantastically powerful compared to “I have the bug in a1b34h but not in 3ae452”. These would be a sequence for a particular centralized branch - typically mainserver/master. Because this is the reality: it’s distributed version control but we almost all use centralized version control. This is also why it’s so odd that Git LFS took years to make it into git. Why would I want all past revisions of a binary (Yes, binaries must often be in version control, whether anyone thinks it’s a bad idea or not)?

russdill 8y ago
That's why most people tag their builds with git describe. It can easily tell you the most recent tag in the current branch and how many commits away from it the build is, for instance v1.5-15-a55325.

alkonaut 8y ago

These days I’m more interested in a comparison between pijul and git. Pijul actually brings real improvements over git.

_pmf_ 8y ago

Can someone explain how the problem of not being able to get successors causes issues in practice? I don't doubt it does, but I've never personally had a situation where inspecting the graph did not give the information I required in this regard.

FrozenVoid 8y ago

The only version management that i find intuitive is wiki model(i.e. wiki articles). Imagine 3 tasks. 1.Revert 3 git commits. This is one-click revert in wiki. 2.Diff 2 arbitrary commits. One-click in wiki. 3.change 2 lines of code. Edit->Submit in wiki. Why git has to be so arcane, especially reverting to specific point in time? The first code versioning control system that emulates the wikipedia UI model will win the market.

smarnach 8y ago

The list of reasons not to use Git seems as smug as it is uninformed. > With Git, it is very difficult to find the successors (decendents) of a check-in. "git log --children" and "git log --reverse" are very difficult indeed. > Fossil users only need to think about their working directory and the check-in they are working on. That is 60% less distraction. Since Fossil is a distributed version control system, there is also remote state to keep in mind. I don't know Fossil, so I don't know the details, but simply pretending the remote state does not exist seems at least misleading. > Setting up a website for a project to use Git requires a lot more software, and a lot more work, than setting up a similar site with an integrated package like Fossil. Setting up GitLab with Omnibus takes about five minutes. It's not Git itself, but rather a third-party package, but why should I care? (And in general, I wouldn't set up anything at all – I'd just use GitHub or GitLab or Bitbucket for my open-source software.) It's fine for different people to prefer different tools. Git can be annoying at times. However, it's a blessing that the open-source community is moving towards a standard everyone can work with, and Git is Good Enough to be that standard. Using an obscure alternative and justifying it with a list of downright wrong claims doesn't seem to create a welcoming atmosphere for new contributors. (And don't get me wrong – SQLite is a great piece of software, and I'm thankful people put in their time to create it.)

smarnach 8y ago
I just learned that SQLite doesn't accept any patches, so the argument that Git is the industry standard doesn't matter to them, and they just use what they prefer.

hi41 8y ago

Speaking truth to power! I like it! I so scared of saying that I never understood git and was getting by using only the most basic of the commands. Now Sqlite has called out!

skandl 8y ago

The refactored page brings up good points. Git has undeniably improved the world of software development, and is de facto the version control system to use in the majority of cases today. That said, that doesn't make the points SQLite makes invalid.