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. Git cannot do that remotely (with exception of git-tar-tree/git-archive which has --remote option), yet. But you can get contents of a file (with "git cat-file -p [<revision>:|:<stage>:]<filename>"), list directory (with "git ls-tree <tree-ish>") and compare files or directories (git diff family of commands) without need for working directory. AFAICT working area is required _only_ to resolve conflicts during merge. > 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") In git by default in the top directory of working area you have .git directory which contains whole repository (object database, refs (i.e. branches and tags), information which branch is current, index aka. gitcache, configuration, etc.). You can share object database locally (which includes network filesystem). You can have .git (usually <project>.git then) directory without working area. And you can symlink (and in the future "symref"-link) .git directory. > 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. There was proposal to allow for tracking branches to be marked read-only, but it was not implemented yet. But git has reverse check: it forbids (unless forced by user) to fetch into branch which has local changes (does not fast-forward). This make sure that no information is lost. The idea is that you fetch changes into tracking branch (e.g. 'master' branch of some parent remote repository into 'origin' or 'remotes/<repository name>/master' branch); you don't commit changes to such branch. You do your own work either on 'master' branch, then merge (typically using "git pull") corresponding 'origin' tracking branch, or use separate private feature branch and use rebase after fetch. [...] > 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. Git is designed for distributed workflows, not for centralized one. All repositories are created equal :-) -- Jakub Narebski ShadeHawk on #git and #revctl Poland - 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