This is why I wish Fossil were less opinionated and supported rebase and exposed branches and tags as the light-weight names that they are underneath the covers (just like git). Fossil uses SQL, which means that all of the things @csswizardry and much more that no git developer has ever thought of.. can be done with a little bit of SQL.<p>But no, Fossil's UI is like Mercurial's, and it favors merging over cherry-picking and rebasing. Their loss!<p>Fossil does have a cherry-pick operation, and anyways, one could trivially be constructed. Which means that rebase can also be constructed easily enough. But my impression is that the devs aren't interested in such contributions. And the heavy- vs. light-weight branching model in the UI is a big turn off even if I can deal with it at the SQL level. Fossil's push/pull model ([auto]sync everything) is also not to my liking -- sure, in a corporate environment pushing every branch is a good idea, but in an open source world it's not: I may want to push some branches to one upstream, others to another, and yet others not at all.<p>This is what I like about git:<p>- the index<p>- git exposes the Merkle hash tree concept at the lowest layer<p>- git branches and tags are just symbolic pointers to commits (see previous point)<p>- support for many remotes<p>- git is not opinionated -- if you want to use a merge-based workflow, you can, and if you want to rebase instead, you can, and if you have to use e-mail to exchange commits, you can, and so on.<p>I'm done with the Mercurial "you do what we say" model. A model they keep half-way reneging on, adding bookmarks (which don't work well), and histedit and rebase (why not both in one command?! "because we don't like git rebase" is the answer I imagine) (they really need to be one command!! what if in the process of rebasing you must drop commits that you know duplicate others in the new base?!).<p>I wish Fossil's developers saw this. But they're focused on their needs: VCS for SQLite3. Since they seem to have few topic branches, they like merging.<p>Conversely, since Fossil's devs refuse to be non-opinionated, I wish git's developers saw the power of SQL for VCS. It would save a ton of code C and shell code, and it would make new extensions trivial. It also would make git much more power-failure safe: since it could leave that to something like SQLite3 that does a fantastic job of it (and is very well tested, both in general and as to power failure safety).<p>Besides this, I wish git has branch history. That is, a single push can push multiple commits by different authors, so it would be nice if one could see who pushed what commits. This would be useful as documentation in and of itself: if you see N>1 commits pushed together and need to revert one of them, you might look at whether you need to revert the rest as well, as they might go together. (Some codebases like to push regression tests first, bug fixes after. This allows one to see that tests detect the bugs they're testing for and that corresponding bug fixes fix those bugs. If one has to revert a bug fix commit, one might have to also revert a corresponding test commit.)