On Jan 04, 2014, at 05:15 AM, Stephen J. Turnbull wrote:

>It's true that Bazaar has some useful features, such as shared repos,
>whose performance characteristics are hard to emulate accurately in
>git.  I can't speak to Stefan's experience, of course, but when I look
>at my git repos, in fact sharing is quite high because branches in
>separate repos tend to be very divergent (so only the original shared
>objects *can* be shared), and when the main feature branch gets
>merged, the whole repo usually gets deleted so the failure of "git
>fetch" to hardlink pulled objects isn't a big space leak.

I know Stephen knows this, but Bazaar shared repos are really just a way to
efficiently store revision objects in a parent directory, such that you can
have a number of subdirectories inside there that represent working
directories of different branches.  Or put it another way, it just moves the
.bzr directory up one level so everything underneath it can share that.  In
most cases, most branches share probably 90% of their revisions, and that's
what makes local branching and remote pulling into a shared repo pretty fast.

I'm another big bzr fan, and while colocated branches are interesting, I find
them to be completely counter to my way of working.  If I'm going to be
working on a number of branches, I want separate working directories for each.
So for example, in Mailman (under bzr) I'll have a shared repo directory
containing working directories each containing a different in-progress feature
(topic) branch.

For Python hg's and other projects git repos, I basically have multiple clones
inside a parent directory that's nothing special.  It works, but doesn't map
to my way of working as well as bzr.

The other thing I sorely miss when working with git repositories is bzr's main
line of development approach.  Once you understand this, and use it correctly
(i.e. merges in the right direction), it's a very nice simplifying feature.
It allows you to have human friendly revision numbers[1], with dotted revision
numbers for side branches.  More importantly, it means that there's no cultural
pressure for history changing rebases, `bzr log` by default only follows the
main line (so side branches are hidden by default, unless you *want* to see
them), and bisect doesn't make you unhappy by landing you in non-working
revisions.

I think if git had this concept and --help text that wasn't 20 pages long (629
lines for `git merge --help`!) it would go a long way to improving the user
friendliness of git, IMHO of course.

That said, it's pretty clear that git has won this round of dVCS wars.
Mercurial will probably hang on and hopefully even thrive as a viable
alternative, but network effects have given git most of the mindshare.  At
least until something better comes along, as it has with CVS and svn in their
times.

-Barry

[1] Yes, they are local-only, and yes they can change, and yes you still have
unique hashes to unambiguously reference a revision, but it's still darn
convenient.  I'd much rather say "Are you on revision 7250 of branch
lp:mailman?"