Matthieu Moy wrote:

quoted text
> Jakub Narebski  writes:

>

>>> - you can use a checkout to maintain a local mirror of a read-only

>>>   branch (I do this with http://bazaar-vcs.com/bzr/bzr.dev).

>> In git you can access contents _without_ checkout/working area.

>

> Bazaar can do this too. For example,

> "bzr cat http://something -r some-revision" gets the content of a file

> at a given revision. But that's not what Aaron was refering to.

>

> In Bazaar, checkouts can be two things:

>

> 1) a working tree without any history information, pointing to some

>    other location for the history itself (a la svn/CVS/...).

>    (this is "light checkout")

>

> 2) a bound branch. It's not _very_ different from a normal branch, but

>    mostly "commit" behaves differently:

>    - it commits both on the local and the remote branch (equivalent to

>      "commit" + "push", but in a transactional way).

>    - it refuses to commit if you're out of date with the branch you're

>      bound to.

>    (this is "heavy checkout")

> 

What about
3) getting the repo with all the history while still not having to be

online to actually commit to *your* copy of the repo. When you later get

online, you can send all your changes in a big hunk, or let bazaar email

them to the maintainer as patches, or...
> In both cases, this has the side effect that you can't commit if the

quoted text
> "upstream" branch is read-only. That's not fundamental, but handy.

> 

It appears we have different ideas of what's handy. Perhaps it's just a

difference in workflow, or lack of "email-commits-as-patches" tools in

bazaar, but the ability to commit to whatever branch I like in my local

repo and then just send the diffs by email or please-pull requests to

upstream authors is what makes git work so well for me. I can ofcourse

also pull the changes to another branch, or cherrypick them one by one,

or...
OTOH, if by "commit" you mean "send your changes back to central

server", and bazaar'ish for "register my current set of changes in the

local clone of the repo" is called something else, it sounds very

similar to what git does.
>

quoted text
> The more fundamental thing I suppose is that it allows people to work

> in a centralized way (checkout/commit/update/...), and Bazaar was

> designed to allow several different workflows, including the

> centralized one.

> 

Centralized works in git too after a fashion. Most projects have a

master repo hidden somewhere that frequently gets pushed out for

publishing and which most (all?) contributors sync against from time to

time, but it's by no means a certainty. What *is* a certainty is that

the published branches are exactly identical to the ones in the master

repo, and all the downstream authors will get a history where they can

easily track master's development.
For git, I suppose Junio has the hidden master repo which he publishes

at kernel.org. Linus does the same with the Linux repo.
On a side-note, it sounds as though the "bound branch" scenario

encourages making a big change as one mega-diff, so long as it

implements one feature, whereas the git workflow with topic-branches

that eventually gets merged to master allows changes to sort of

accumulate up to a feature in the steps one actually has to take to make

the feature work.
Side-note 2: Three really great things that have made work a lot easier

and more enjoyable since we changed from cvs to git and that aren't

mentioned in the comparison table:

* Dependency/history graph display tools