Matthieu Moy wrote:
quoted text
> Jakub Narebski <jnareb@gmail.com> 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...

quoted text
> In both cases, this has the side effect that you can't commit if the
> "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