Breezy Version Control System
breezy-vcs.org
breezy-vcs.org
It has a very simple and easy to understand model. It was comfortable to those used to a more centralized style (like csv/svn), but gave you offline commits/history, branching, excellent merging, and good tools to look at history.
All developers needed to know where: checkout, pull, commit, push, diff, log, and merge. It worked on _all_ platforms, new people to version control never struggled with it, and tools like Tortoise and Trac supported it. There was no confusion about remotes, detached heads, or anything like that.
Unfortunately, by 2010-2012, it was clear that git was going to be the winner, and our younger developers wanted to use it and github. We did eventually migrate all projects to git.
I still have some personal projects that I use breezy with, although, all new projects I use git now.
One of my favorite aspects is how it shows history and merging. `bzr log` only shows commits directly on that branch. So if you are looking at the master branch that has commits A, B, and C, if someone goes off and works on D and makes commits D1, D2, D3, when D is merged into master, you now just see A -> B -> C -> D, where D is everything from D1+D2+D3. You can off course break down D into its sub-commits (and sub-merges, like when you merge master back into a branch), but as a default, this leads to a really clean history. No arguments over squashing / rebasing / FF-only / merge-commits, etc.
I think Git supports this with "git log --first-parent", to show only the merge commit, doesn't it? That's what I gathered from a discussion here some time ago on branching strategies.
These are the commands the overwhelming majority of git users will use the overwhelming majority of the time:
clone / checkout (or switch) / commit / merge / rebase / diff / stash
Yes, hacking around with the reflog and fixing up weird situations with git is ... tricky and hard to remember.
But the vast bulk of git usage is easy and easy to remember.
It's easy from the perspective of someone who already understands its conceptual model, which is wonderfully elegant. It's not at all easy for beginners.
The happy path is fine for the most part. There are several conceptual hurdles to developing basic competence with add, commit, push, and pull, but usually people are able to push past them and get to the point of using those commands even if their purpose and mechanism of action remain mysterious.
But things immediately go to hell if something deviates from the happy path. Have you ever seen a beginner try to wrap their head around a merge conflict? Have you ever seen someone try to puzzle through the man pages and Stackoverflow to figure out how to recover from a situation when they can't push, due to remote changes? It often ends in disaster, as they stumble through increasingly opaque and arcane commands, as they mess up the state of their local repository ever further with every copied and pasted snippet.
This is not a case of newbies trying to do advanced things they shouldn't be doing. These are "advanced beginner" tasks that arise naturally at some point in just about any workflow.
Of course, a lot of this can be ascribed to general lack of competence in doing computer stuff. But Git seems especially disorienting even to people with high general intelligence and years of experience solving difficult technical problems. There's something about its combination of commands that do not map cleanly to the underlying data model, complicated layers of automatic behavior that are only revealed deep within chatty jargon filled reference manual pages (or can only be found in the source code), broadly inconsistent terminology and UI elements, and CLI that tends to be either too verbose or too quiet by default.
It's hard to learn and hard to teach. That, in my opinion, makes it hard to use.
Once you see the graph change as you move about, it all makes a lot more sense.
If you're interested, here's my version of this:
[alias]
## Pretty log graph
log-oneline = log --decorate=short --date='format-local:%a %F %H:%M' --pretty='tformat:%C(auto)%h%C(reset) %C(auto,blue)[%ad]%C(reset)%C(auto)%d%C(reset) %aN: %s'
log-graph = log-oneline --topo-order --graph
reflog-oneline = log-oneline --walk-reflogs
lg = log-graph
lgl = log-graph --branches --tags
lgr = log-graph --branches --tags --remotes
lga = log-graph --all
%C(col) Change color to "col"
%h Abbreviated commit hash
%ad Author date (formatted as per --date)
%d Ref name (like with --decorate)
%aN Author name
%s "Subject" (first line of commit message)
Add in different code review tools and practices and it gets a bit crazy.
Mercurial and Bazaar (and in fact Bitkeeper itself when I looked at it back in the day) tend I think to have far more assumptions baked into the CLI about how you'll use them -- or at least they started that way. I think for most teams this is in fact superior, but that's not how the industry went. Because github caught on in the early days, git itself became synonymous with DVCS and modernized revision control right at the time people were finally figuring out that, yeah, not only does CVS suck but Subversion isn't really an improvement.
Back then I remember it being often very hard to convince people to try anything new at all, just even to get off CVS. A lot of suspicion, with SVN accepted as a kind of tolerable compromise because it acted mostly like CVS but better.
And then the industry kind of just jumped all at once to git, and that was that.
Rebasing is very easy to understand if you treat commits as diffs. Commits are stored as snapshots. But operations like rebase and merge act on diffs introduced by the commit (often that action is a 3-way merge). For example, when you drop/delete a commit while rebasing, the change introduced by that commit is removed from all subsequent commits.
Meanwhile, another problem is that you can easily get lost if a rebase is interrupted by a conflict. This would have been easier if you could see the commits as diffs. The easiest way out I found is to do no more than 2 operations per rebase. You can do as many rebases as you wish.
Wierd situations very rarely seem happen to me. At worst you just git reset --hard to something sensible. If you're nervous about doing something, make a tag before you do it at your current HEAD location (git tag "pre-drama-tag-here-we-go") and you'll always be able to tap your heels and go home without even having to find the right hash.
But it is not the default. Which means if you check out the project and just do git log, you won't get an ideal story. Same goes with GUI tools and github. Those basically become useless.
PS: This is based on my vague memory of using bazaar a long time ago. I had to look it up again to confirm.
So what's the point? Is it just for people to hack on?
* which is bizarre, pun intended
https://en.wikipedia.org/wiki/GNU_Bazaar#Breezy
Bazaar was forked as Breezy in 2017 to allow backwards-incompatible changes to be made, such as migrating from Python 2 to Python 3 and dropping support for older versions of Windows.
Specifically, in what way is Breezy an improvement over existing DVCSes
Still I agree that the page doesn’t show much.
This is probably not at all important today, but things were different 17 years ago.
https://stackoverflow.com/questions/5533912/what-is-a-simple...
We evaluated it at a shop I was a lead at back then. Worked fine enough, though we ended up using Mercurial, which had similar advantages over git -- cross platform, and CLI was more intuitive, but in most respects similar to git, etc (because it, like git, was inspired by bitkeeper, ec.).
Git is... fine. But I wish the young and unaware would stop imagining that it's somehow the entire horizon of revision control.