5 ms·

When moving from subversion to a DVCS around 2006, we evaluated git, bazaar (now breezy), and mercurial. This was before github, and git was really tied to the

by l72 3y ago

When moving from subversion to a DVCS around 2006, we evaluated git, bazaar (now breezy), and mercurial. This was before github, and git was really tied to the development style of the linux kernel. I can't remember exactly what issues we had with mercurial, but everyone in the group loved bazaar. 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.

ptx 3y ago
> `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. 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.
- gizmo 3y ago
  Not being quite sure how git deals with this even though, as the parent argues, it is the sensible default behavior, is really the problem. Everything is possible with git but nothing is easy or easy to remember.
  - PaulDavisThe1st 3y ago
    > Everything is possible with git but nothing is easy or easy to remember. 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 Time to stop the "nothing is easy" fairy tale. 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.
    - nerdponx 3y ago
      As a very satisfied long time Git user who also ends up being its biggest advocate and trainer at any organization I end up at... no, it's not easy. 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.
- l72 3y ago
  Correct, `--first-parent` will show a similar view. We do a merge-only strategy with git, so using --first-parent is very important in our workflow. 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.
- rbehrends 3y ago
  The difference between Git and Bazaar/Breezy is how it handles displaying branches. In the latter case, you're getting a hierarchical log by applying the approach recursively, not a graph, which (IMO) is the better visualization. As an added bonus, you also get a canonical revision numbering scheme and don't have to use hashes to identify a commit.
petre 3y ago
Does it keep each branch in its own directory? Because that's what the docs seem to suggest.
- goku12 3y ago
  Breezy branches are similar to git or mercurial repos. Breezy doesn't have branches within a repo. Breezy branch command does essentially what git or mercurial clone command does. So, yes - breezy stores branches in its own directory. PS: This is based on my vague memory of using bazaar a long time ago. I had to look it up again to confirm.

by l72 3y ago

ptx 3y ago

> `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. 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.

gizmo 3y ago
Not being quite sure how git deals with this even though, as the parent argues, it is the sensible default behavior, is really the problem. Everything is possible with git but nothing is easy or easy to remember.
- PaulDavisThe1st 3y ago
  > Everything is possible with git but nothing is easy or easy to remember. 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 Time to stop the "nothing is easy" fairy tale. 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.
  - nerdponx 3y ago
    As a very satisfied long time Git user who also ends up being its biggest advocate and trainer at any organization I end up at... no, it's not easy. 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.
l72 3y ago
Correct, `--first-parent` will show a similar view. We do a merge-only strategy with git, so using --first-parent is very important in our workflow. 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.
rbehrends 3y ago
The difference between Git and Bazaar/Breezy is how it handles displaying branches. In the latter case, you're getting a hierarchical log by applying the approach recursively, not a graph, which (IMO) is the better visualization. As an added bonus, you also get a canonical revision numbering scheme and don't have to use hashes to identify a commit.

petre 3y ago

Does it keep each branch in its own directory? Because that's what the docs seem to suggest.

goku12 3y ago
Breezy branches are similar to git or mercurial repos. Breezy doesn't have branches within a repo. Breezy branch command does essentially what git or mercurial clone command does. So, yes - breezy stores branches in its own directory. PS: This is based on my vague memory of using bazaar a long time ago. I had to look it up again to confirm.