Aaron Bentley wrote: > Linus Torvalds wrote: >> If you want a short, human-readable name, you _tag_ it. It takes all of a >> hundredth of a second to to or so. > > But tags have local meaning only, unless someone has access to your > repository, right? Tags are propagated during clone, and during fetch/pull (getting changes from repository). So in that sense they are global. If you don't publish your repository, then neither tags, nor <URL>+<rev no> has any sense, any meaning to somebody other than local private repository. >> Well, in the git world, it's really just one shared repository that has >> separate branch-namespaces, and separate working trees (aka "checkouts"). >> So yes, it probably matches what bazaar would call a checkout. > > The key thing about a checkout is that it's stored in a different > location from its repository. This provides a few benefits: > > - you can publish a repository without publishing its working tree, > possibly using standard mirroring tools like rsync. git clone --bare > - you can have working trees on local systems while having the > repository on a remote system. This makes it easy to work on one > logical branch from multiple locations, without getting out of sync. In git we usually use "git clone --local" (with repository database hardlinked) or "git clone --shared"/"git clone --reference <repository>" (which automatically sets alternates, i.e. file pointing to alternate repository database) for that. This way one gets his/her own refs namespace, so two people can work on different branches simultaneously. Alternate solution would be to symlink .git, or .git/objects (i.e. repository "database"). > - 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. For example gitweb (one of git's web interfaces) uses only repository database and doesn't need checkout/working area. >> Almost nobody seems to actually use it that way in git - it's mostly more >> efficient to just have five different branches in the same working tree, >> and switch between them. When you switch between branches in git, git only >> rewrites the part of your working tree that actually changed, so switching >> is extremely efficient even with a large repo. > > You can operate that way in bzr too, but I find it nicer to have one > checkout for each active branch, plus a checkout of bzr.dev. Our switch > command also rewrites only the changed part of the working tree. Luben (IIRC) works this way. -- Jakub Narebski 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