VCS comparison table

[Matthieu Moy]

Carl Worth <cworth at cworth.org> writes:

> Yes. We're identifying the core underlying technical difference behind
> the recent discussion. Namely bzr treats one parent as special, (the
> parent that was the branch tip previously). And this special treatment
> eliminates the ability to fast-forward, 

No.

bzr could trivially do fast-forward too. It's an explicit design
decision to have two separate commands.

> adds merge commits that wouldn't exist with fast forwarding,

They don't exist either with "pull".

The difference between bzr and git is smaller than you think on this
point I believe.

> There's a bit more to it than that though. The git command named
> "pull" will perform a fast-forward if possible, but will create a
> merge commit if necessary. For example:

The bzr command "pull" will do a fast-forward if possible, but will
refuse to continue and ask you to create the merge commit with other
commands if necessary.

> 	a       a                      a
> 	| pulls | and fast-forwards to |
> 	b       b                      b
> 	        |                      |
> 	        c                      c

Same as bzr.

> whereas:
>
>         a       a                       a
>         | pulls | and creates a merge  / \
>         b       c                     b   c
>                                        \ /
>                                         m

Here, bzr will refuse to pull. It will say "branches have diverged"
and tell you to use merge.

Then, you'll do

$ bzr merge

# optionally "bzr status"

$ bzr commit -m "merged such or such thing"


So, "git pull" seems roughly equivalent to something like

$ bzr pull || (bzr merge; bzr commit -m merge)

> So I'm curious. What does bzr pull do in the case of divergence like
> this? (And this is the "numbers will be changed" case, by the way).

Not yet. The "numbers will be changed" is if b pulls, right after.


Then, one other difference is in the UI. bzr shows you commits in a
kind of hierarchical maner, like (fictive example, that's not the real
exact format).

$ bzr log
commiter: upstream at maintainer.com
message:
  merged the work on a feature
  ------
  commiter: contributor at site.com
  message:
    prepared for feature X
  ------
  commiter: contributor at site.com
  message:
    implemented feature X
  ------
  commiter: contributor at site.com
  message:
    added testcase for feature X
------
commiter: upstream at maintainer.com
message:
  something else

No big difference in the model either, but it probably reveals a
different vision of what "history" means.

-- 
Matthieu