I switched to Fossil a few months ago. Nice website that holds all the information. fossil commit -m "Message" is all they need to know. If they forgot to pull, it stops and tells them to do so. They type fossil update and go on with their lives. Zero problems so far and a more productive workflow overall.
I think a lot of devs have the attitude that a tool being more difficult to use makes it a powerful one (cf. Vim/Emacs), whereas most people are happy when tool does the three things they need to get from a=>b, b=>c, a=>c.
Maybe this is to do with our desire for everything to be as flexible as the programming languages we write in. Most people don't view computers as blank slates ready to do their bidding, but as systems where the behaviour of a few facets is to be memorised without concerns for their mechanics or abstractions. This is probably one of the reasons that mobile software is seen as so easy to use, since it obscures/abstracts elements like the filesystem from the user.
Glad to hear Fossil is friendlier.
EDIT: I should say that I am a heavy user of Vim, Emacs, Git and Arch Linux, I am just saying that these tools often require a large up front investment, and this can be detrimental as well as sensible.
This is more up to git being horribly leaky about all it's internal implementation details. I'm not a git developer, and not even that great a user, but I know about trees and indices and refs and refspecs and packs and reachability and objects and merge drivers and smudge and clean and diamonds and countless other details that I feel should be encapsulated way better. git also has next to none documentation of these concepts.
Git is unapologetically a tool for manipulating a DAG, and puts that right in your face.
This has pros and cons. The obvious con is that it has an immensely steep learning curve and, for users who cannot develop a mental model for how it works, forces people to rely on cargo culting.
The flipside is that it's more powerful than any SCM I've worked with, as the lack of any abstraction means you can do nearly anything you like to that DAG.
Heck, let's take this example originally posted. The remote repo has changed. Okay, well, the common case is probably to pull and... wait, merge or rebase local changes? Git gives you the choice. Other tools might not.
All that said, git could certainly be made a lot less esoteric. The command set is inconsistent and poorly named (I'm looking at you 'git reset'). And the error messages leave a lot to be desired.
As for doc, I completely disagree. I've built git training modules and my primary sources are the git docs. They're quite thorough (though they have the fault of being heavily steeped in git jargon).
So you actually agree. To understand the docs you have to understand git jargon, and the docs aren't too helpful about that.
I certainly don't want to say that the git docs are bad. They're quite complete and written in mostly complete sentences, which is already pretty good as far as documentation goes. Doesn't mean that there is a lot of room for improvement.
While I agree that there are those who take pride in how spartan tools they use, it's not correct to make blanket judgements about the whole suite of hackerware. Emacs, for instance, is not difficult to use, it is a different computing environment, which, when you get hold of it, can boost your productivity. I've written many little programs in it that I use every day which I'd never be able to write in other languages because a) I need to know at least one GUI framework and many other libraries, b) no other environment has the same use-hack-eval-use development experience, and c) the way you create GUIs in Emacs is so effective (mixture of special-mode, plain text and text with properties attached; all buffer-manipulation commands come in to your app out of nowhere, gratis) that one can set sth. working in their first hacking session, and then on improve their tools while using it, all interactive, whereas in all other GUI frameworks you're left alone with widgets and a dev cycle that's nearly always approximately write-compile-debug-compile.
Git, instead, is a plain tool for one purpose with an arcane user interface. I believe the patch theory school of VCS tools (e.g. darcs) will overtake in future when they'll smooth out their rough edges as they provide a very intuitive way to work with code as a series of related changes.
In order to get it to do half of what Notepad++ or Sublime or Kate do, you have to spend hours and hours to learn it and configure it in the hope that the investment will pay off and that the productivity gain will make up for it. And despite what you might say there's no data you can point me to that actually proves those increased productivity claims.
The actual power of Emacs is realized once you learn elisp. Coding, documenting, commiting, blogging, browsing, file/dir manipulation, etc. all can be done efficiently using the same familiar buffer editing philosophy within Emacs.
Do they have anything remotely like Gnus or Org-mode? Tramp? Magit? VC mode? SLIME? EMACS IS NOT A TEXT EDITOR. It is a Lisp interpreter with many applications written in it which happens to have a text UI and a text editor in its standard distribution.
Some of us never forget. And "esoteric" is way to kind a word for that thing, it is abstraction leak made software.
No, it just might be more powerful once you get past the initial difficulty of learning how to use it enough.
git branch foobar
git branch -m barfoo
git branch -f barfoo
git branch -d barfoo
# change WD to branch
git checkout foo
# change WD to state of HEAD
git checkout -- .
# change WD to new branch forking HEAD
git checkout -b bar
> mean that git gets useful new features?
I don't really understand what you mean by this. Is something only 'powerful' if it 'gets useful new features'?
I'm not saying it's easy for newcomers, I'm just saying the difficulty is biased to the early stages of the learning curve (I certainly experienced it, I used to fear git - now I fear lack of it) and disputing the claim that it isn't powerful.
Having checkout handle creating branches is strictly a shortcut. The other option for the shortcut would be for `git branch` to sometimes alter state in your working directory (it currently never does this). The non-shortcut version (which works today) is to only create branches with `git branch` and only checkout branches with `git checkout`.
If you look at it from the perspective of "checkout is the thing that screws with your local working directory", it is organized logically.
The only problem is that once the history gets big enough, fossil gets slow. Everything is replicated everywhere which is an advantage (backups everywhere) but also a drawback (slow). I once tried to convert the FreeBSD ports tree to fossil and gave up after some hours and gigs of data.
Mercurial was interesting and user friendly as well, but it requires python. Fossil is a single self contained binary with everything in it. And so is the repo - a single SQLite database. No .svn dirs scattered all over the place.
also, you do know that conflicts are going to show up eventually right?
The workflow doesn't avoid conflicts.
> keep all the power of git to who need it
Git provides no useful features over Fossil for what we're doing.
> you do know that conflicts are going to show up eventually right
And when they show up with Git, boy do they show up.
But I still miss Fossil. I like the simplicity, and the feature set (although last I looked it still didn't do rename tracking), and the immutable nature of the database... I particularly liked the way that it's also a webserver. Being able to have your project web in a branch and when you want to make it live you just atomically update a tag is beautiful.
The wiki I never used much, preferring to use manually version-controlled markdown files instead. The bug tracker... actually works pretty well, but it needs a lot of setup before it looks and feels anything other than ropy. (Although this may have changed. When I stopped following fossil it was undergoing a big UI overhaul.)
If it supported bidirectional git sync, I'd switch back in a heartbeat.
Update: having just fetched the latest version from Debian, there's lots of new stuff. 'fossil fusefs' lets you mount the repository as a read-only filesystem, which is cool. There's better support for private branches. There's a monster machine-readable interface based around json data packets. You can now have unversioned but synced files? Possibly this is for big binaries where you don't care about history? There's a 'fossil stash'. There's full-text search. You can export bundles of changesets so you can pass them around (pull requests, basically).
Oh, and 'fossil praise' and 'fossil blame' are synonyms.
It looks like there is support for git bidirectional sync, but it looks a bit hacky:
But that was, like, 2011, so I have no idea if it's still valid or not.
The builtin Wiki was what really sold me on it, because it makes a great place to gather notes and such.
This is one nice piece of software, at least for my needs.
If I'd had some form of user-database already, I could probably have gotten it to work with a proxy in front - but for now I've ended up using gogs: https://gogs.io/
I'm not certain I actually prefer gogs to fossil, but apart for working as I wanted/needed without much setup it had the dubious benefit of forcing me to teach my students to use git, along with a rather cumbersome pull-request system (gogs tend to hickup on commits that probably should've been possible to fast-forward, possibly due to not forcing git to ignore white-space).
Dubious because as a bit of a mercurial fanboy, I think git has a frustrating and opaque command line interface, not helped by the fact that a standard workflow uses various "non standard" (as in: the most obvious) commands. Benefit because learning git is unquestionably a valuable skill, due to the popularity git enjoys, in no small part due to github's success.
I'd like to go back and revisit Fossil at a later time, but right now I'll probably spend any time I can find on (investigating) migrating from gogs to gitlab -- as it's turned out that the limits on pull-requests in gogs make it complicated to use with large groups of people new to version control.
That said, I'm a strong believer in combining wiki, version control and issues in a single repository supporting various DVCS workflows.
I setup a personal Gitea instance on Linode, but wanted to make sure I could easily back up my repos in case I ever lose access or stop maintaining my personal Linode server.
Gitlab made it easy to setup all of my repos to mirror and automatically update from my Gitea daily.
(One slight bug, Gitlab does seem to always say the repos failed to import, even when they're successful)
Thanks for the helpful feature!
I'll check that out first I think - I really like the ease of deployment with gogs, so if the project have some features a little more ironed out - it might be just what I need.
Nice to see - I think that good tools should have UIs that at least come close to the quality of their engineering.
But to me, the most beautiful UI is one that offers the functionality I need while remaining lightweight.
Fossil's UI is very fast and the navigation is intuitive and discoverable.
I know it's on the roadmap, but it is so often an afterthought.
I've clicked around in the UI of Fossil. It indeed is very fast. About the navigation:
1. Fossil has home, GitLab has a hamburger menu with different top level view, Fossil doesn't seem to account for multiple project but I'm probably overlooking something.
2. Fossil timeline seems similar to GitLab Activity https://gitlab.com/gitlab-org/gitaly/activity
3. Fossil code seems similar to GitLab Repository https://gitlab.com/gitlab-org/gitaly/tree/master
4. Fossil docs seems similar to GitLab help https://gitlab.com/help (in this case, for other projects I think it has the documentation of the project, not sure what standard they use)
5. Fossil branches are in the GitLab repo view
6. Fossil tickets are similar to the GitLab issues view
7. Fossil wiki is similar to GitLab wiki
8. Fossil includes a download tab, in GitLab that would be the tags view https://gitlab.com/gitlab-org/gitaly/tags to download the repo (not sure if this is always to download Fossil or the specific project)
9. The Fossil "More..." link looks like a sitemap.
What would you change in GitLab to make it more discoverable?
Also handy is the Fossil timeline includes more than just commits, it includes Commits, Wiki changes, Change artifacts, Technotes, and ticket creation/updates so you can get a sense of how things happened in time.
Also, Fossil supports serving multiple repositories -- it's just a matter of how you start it, but since it's all integrated there's not a lot of reason to use that functionality usually. ChiselApp uses Flint ( https://chiselapp.com/user/rkeene/repository/flint/ ) to handle the administrative task of creating repositories, taking in repositories as uploads, resetting repository passwords if you have access to the ChiselApp dashboard, and performing scheduled pulls.
This is admittedly a lot better in Gitlab today that it used to be. When I started, I literally could not figure out basic things like how to get to a specific repository inside of an organization. It also doesn't help that Gitlab has chosen to use its own jargon for each of the basic concepts. A "project" is a "repository" and a "group" is an "organization", etc. I can kind of grok it, but I sometimes do a double take when something isn't where I expect.
For example: In my mental model, "project" == "repository". But when I go to a project home page like say , I don't see a code browser or commit list, or options that obviously take me to either of those. Instead, I have to click the "Repository" tab first. (It turns out that tabs can have second-level tabs, which means those options are hidden initially and thus not discoverable.) But I thought a "project" was a "repository"?
I fully realize the Gitlab notion of "project" may be more general than just a "repository", but this is an example of the sort of cognitive dissonance that I get navigating around the site.
At this point I've mostly made peace with the Gitlab interface, so it's a bit hard for me to pull up examples like this now. And as I said above, the interface has improved. But when I first started using Gitlab, there were a lot of things like this (little points of cognitive dissonance) which made it seriously an uphill battle to even use the product.
In GitLab people can have a project without a repository, for example with just a wiki or an issue tracker. For that reason we use different words for it.
Single people also use GitLab as a single tenant we prefer to use the word group over organization. That will also fit better when we introduce nested groups in GitLab 9.0 https://gitlab.com/gitlab-org/gitlab-ce/issues/2772
Good point about showing files by default, we're discussing that in https://gitlab.com/gitlab-org/gitlab-ce/issues/26834
Thanks for using GitLab!
As eslaught pointed out, it's not about the obvious mistakes.
Unfortunately, the navigation is very fragmented. There's a left menu, which should be the primary one, but it changes all the time depending on the context.
The top menu is very inconsistent, presented in multiple layers, with different styles for each level, using very low contrast text with no other visual aid. There are no dropdowns or other ways to get to frequented pages faster. Being aligned to center also prevents me from memorizing the UI spatially (YMMV).
And there's also the issue with minimalistic buttons acting like links.
It is my humble opinion that rewriting the frontend in Vue will not, by itself, alleviate the matter; however, fixing this part of the UX will make GitHub and Atlassian really run for their money.
To join the discussion see: https://gitlab.com/gitlab-org/gitlab-ce/issues/26348#note_23... or https://gitlab.com/gitlab-org/gitlab-ce/issues/18844#note_23...
Sure you can't do fine grained control or permissions, but for small shops/groups it seems like a good starting point.
That seems like a terrible compromise.
It's hard to measure objectively... but my perception was always that there was an explosion of SCMs around the early-mid 2000s, after everybody got sick of CVS, but eventually Git won out and a lot of the alternatives / diversity in the space went away.
Within short succession, there was Subversion, Arch, Darcs, Quilt, Bazaar, Mercurial. On the commercial side, perforce had a certain amount of traction, and the Linux kernel was using BitKeeper... which no doubt encouraged a lot of the innovation in the open-source space.
Then, once Git was developed, got huge exposure and traction through the Kernel, and GitHub came onto the scene, it quickly became dominant - despite the alternatives, and despite the goofy interface.
Richard Hipp explains the target market at the beginning of this video: https://www.youtube.com/watch?v=-ceEWWqaVsI
Neither have I and I am a bit hesitant to throw all my tooling out of the window (ok, mostly hosted git + git extensions + builtin git + svn support in all my IDEs (Netbeans/VS/Rider).
"Because of its emphasis on recording history exactly as it happened, rather than as we would have liked it to happen, Fossil deliberately does not provide a "rebase" command. One can rebase manually in Fossil, with sufficient perserverence, but it not something that can be done with a single command."
2. Fossil can change meta-information (commit messages, tags, branch names) after the fact. Those changes also leave an audit trail.
3. Fossil has features that handle certain use cases for rebasing (private branches, fossil stash snapshot, etc.). If you absolutely need to, fossil purge can be used to edit local history and the shun mechanism can be used to (e.g.) extirpate sensitive information that was shared by accident.
4. Extensive use of rebasing to produce a linear history is a Git-ism , largely due the fact that in Git, history is a soup of anonymous commit objects that is difficult to visualize. Other version control systems that allow you to label and structure history have less need for this.
I'm mostly a mercurial person, where doing a rebase is highly discouraged and nontrivial. After all these years on mercurial, I've never found a need to do it. Why is it so popular amongst git users?
It's generally not seen as very good to send things upstream that conflict with existing changes, and including merges (from master, primarily) in upstream submissions is frowned upon.
When I was using mercurial, I ended up using the mq extension  to provide a similar work flow. I actually prefer mq's work flow to rebasing in git (simplifies some things when maintaining a set of changes), but the programs like that for git are lacking (I've tried guilt and quilt).
Interactive rebasing lets you avoid that mess, I don't think it is that complicated. Mercurial uses the same underlying data structures, so I don't understand how rebasing can be more complicated on Mercurial than Git.
This is an artifact of Git. There are two principal solutions that do not require rebase.
1. Use Bzr-style hierarchical logs. This could in principle be used as a UI on top of Git. Here, merging rather than rebasing actually improves the readability of history.
2. Have fully labeled branches. This allows you to filter and visualize commit history based on branch membership. This is the approach traditionally used by most non-Git version control systems, but is not really viable in Git, because Git lacks the necessary meta information.
As for "reading through them", I usually use a GUI that shows the commit history, and it will show all the commits in a branch in, well, a branch. I can easily ignore them.
Author and AuthorDate: These will not change during a rebase. Unless maybe you do an interactive rebase and edit the commit... I'm not 100% sure how those interact.
Commit and CommitDate: These will change during a rebase, as a rebase is recreating the commit and that will be done with the current user and date.
On the other hand, it will not show any conflicts resolved during the rebase- it will just look like you knew all along what master was going to look like.
It's more complicated in the sense that there isn't a nice command for it. You still can do it by doing multiple lower-level steps, or installing an extension that makes it nicer.
`hg rebase -s src -d dst`
hq's mq extension can do the same thing with a prettier UI but IMO much worse functionality.
Mostly to sort the code out before publication. People usually assume rebase as a tool for integration but forget how useful it is in the "local" development stage (ie. before pushing the code for the team).
Also, rewriting history (in the good sense of the term).
Git have some awesome approaches for minimizing the amount of semantically irrelevant commits in the repository (or plain garbage commits) that other VCSs lack. Mostly the possibility of having local branches (keeping them hidden away from everyone may be a plus in some cases) were a developer safely store that horrible-looking code everybody says they never write, go back, test, fix the code up, add test cases, fix indentation, documentation, etc. all in different commits and, then, rebase or squash-merge them in a self-contained, well-described and semantically split set of commits and then push them to the public repository in a way other team members can follow and understand.
For git, history is a tool for documenting the project -- and I love it.
I don't find that diamond branch development technique adds much in the way of useful information, so I tend to try to keep it linear.
Rebase may let me replay all of the other changes on top and save me lots of manual effort to get the patch so that it applies cleanly to trunk
It's also written in python so it should be not so hard.
Advantages: The entire repository is a single file (SQLite database), which makes some things easy (backup, putting it on a USB drive, mailing it to another person) and has support for tickets and a wiki built-in. It is simple, but feature-complete for the use cases it is intended for.
Disadvantages: The command line interface is lacking in some regards (which can be fixed through addon tools, but isn't for everybody). In particular, there's a huge feature gap between `fossil ui` and `fossil timeline` for viewing history. Like Git (and unlike Mercurial and Bzr), you're forced to deal with commit hashes rather than numerical version numbers (which can be an annoyance when using annotate/blame, for example). Third-party contribution via `fossil bundle` is too limited IMO; you really want all contributors to have direct access to the repository to be productive.
2. Even local revision numbering has useful applications, such as annotate/blame, where numbers (unlike hashes) follow a chronological ordering. It is still better than not having them at all.
Overall I'd say fossil has its share of warts and it currently doesn't justify the contribution barrier it introduces with enough in return.
Wiki supports the wiki format, markdown, and HTML now.
There is now a "fossil search" command for full-text search (including artifacts, if enabled).
I've never had a username/password failure so no idea what that could be.
For tickets, icomment is probably the solution you want but it's not very intuitive.
git add -p doesn't require a staging area per se, and I could see that being added as part of the commit process... but usually I like to test my changes a little bit before committing (e.g., does this even compile) and I can't do that on a partial commit.
I also use it for many non-public repositories, including the Linux distribution I maintain (with a few hundred packages).
My experience is that it is very convenient and easy to adapt.
I don't know if it's been fixed by now, but back when I was using Fossil regularly there were long-standing bugs where pushing the UI and ticket configuration from one repo to another didn't work properly, so synchronising look and feel across multiple repositories was hard.
These are both things that every project ends up needing, but end up with some different solution, which then ends up with a loose, brittle, custom integration with the SCM - using your ticket name for branches, but the having to look up the details on a website - checkin hooks, these kinds of hacks.
It's not too difficult to imagine some simple, robust setup where the ticket state is and documentation (markdown) is store in the SCM, and you can view it either using the command-line, or fire up a local webserver embedded in the scm tool.
Everybody thought SCM had to be centralized too, until it turned out that it didn't. I can see the same benefits of making local changes to tickets and documentation, then sharing those changes later when they're in a good state.
With Mercurial and Fossil, they worked very intuitively for me.
Also, I like Fossil's tags. At work, I keep a repository of all the scripts I have written, and it really helps to associate individual commits with individual scripts.
(I mean, don't get me wrong, if you like Git, by all means, use it. But for my workflow, it is far too complex.)
Additionally, the fact that the bug tracker, wiki, and technotes/milestones are all distributed as part of the same database is very helpful.
Unversioned artifacts have been added recently, which are helpful for storing and optionally transmitting build artifacts associated with the repository.
No multi-stage commit pipeline is much easier conceptually -- mostly I just want to commit the changes I made to my repository and automatically sync upstream.
The code is simple and easy to modify -- I added tarball support (in addition to zip; but I think DRH rewrote the implementation that is in use) as well as S/MIME signing of commits (in addition to GPG -- to use X.509v3/PKI for more robust signing)
I'd guess that the majority of projects are small development teams and this is the point of Fossil -- it works well for small development teams.
When the Tcl developers were looking to migrate from Sourceforge to a new system, they picked Fossil over Git for a couple of reasons. Ease of use was one of them.
But forcing this approach precludes you of, for example, easily splitting your existing changes in two commits if required. If changes to the same file are to be committed separately, a non-zero amount of copy-pasting, resetting, temporary files, etc. will be required.
I see Git's separation of concerns of a strict superset for your use case. Just add an alias "git commit -a; git pull; git push".
You can turn autosync off in which case the fossil/git push/pull doesn't happen and your commit goes straight to the repository -- still without a staging area.
This is my personal usage but, if two changes to the same file are to be committed separately (e.g., git add -p) then the commit that should have happened for those separate changes that was tested just got missed, or the commit that is occurring is untested and perhaps incoherent. That is to say, I build my staging area out of files on disk at the same time rather than building a changeset that may have never actually existed on disk.