Matthieu Moy wrote:
Jakub Narebski <jnareb@xxxxxxxxx> 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
"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.
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 á la qgit/gitk
* Bisection tool for finding bug introduction revisions.
* Tools for sending commits as emails.
--
Andreas Ericsson andreas.ericsson@xxxxxx
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html