Sean <seanlkml@xxxxxxxxxxxx> writes: > On Tue, 17 Oct 2006 13:19:08 +0200 > Matthieu Moy <Matthieu.Moy@xxxxxxx> wrote: > >> 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") > > Git can do this from a local repository, it just can't do it from > a remote repo (at least over the git native protocol). However, > over gitweb you can grab and unpack a tarball from a remote repo. > In practice this is probably enough support for such a feature. Anyway, given the price of disk space today, this only makes sense if you have a fast access to the repository (otherwise, you consider your local repository as a cache, and you're ready to pay the disk space price to save your bandwidth). In this case, it's often in your filesystem (local or NFS). >> 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") > > This doesn't sound right, at least in the spirit of git. Git really > wants to have a local commit which you may or may not push to a > remote repo at a later time. There is no upside to forcing it all to > happen in one step, and a lot of downsides. Gits focus is to support > distributed offline development, not requiring a remote repo to be > available at commit time. I lied in my above description ;-). I should have said "by default" ... but you have "commit --local" if you want to have a local commit on a bound branch (at this point, I should remind that not all branches are "bound branches". "bzr branch" creates branches similar to git ones). >> 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. > > Again this seems really anti-git. There is no reason for your local > branch to be marked read only just because some upstream branch is > so marked. Will, take the example of my bzr setup. I have one repository, say, $repo. In it, I have one branch "$repo/bzr.dev" which is an exact mirror of http://bazaar-vcs.org's branch. I also have branches for patches (occasional in my case) that I'll send to upstream. Say $repo/feature1, $repo/feature2, ... If, by mistake, I start hacking on bzr.dev itself, I'll be warned at commit time, create a branch, and commit in this new branch. I believe git manages this in a different way, allowing you to commit in this branch, and creating the branch next time you pull. But you know this better than I ;-), I never got time to give a real try to git. >> I use it for example to have several "checkouts" of the same branch on >> different machines. When I commit, bzr tells me "hey, boss, you're out >> of date, why don't you update first" if I'm out of date. And if commit >> succeeds, I'm sure it is already commited to the main branch. I'm sure >> I won't pollute my history with merges which would only be the result >> of forgetting to update. > > This is exactly the same in Git. You really only ever push upstream > when your local changes fast forward the remote, (ie. you're up to date). > Git will warn you if your changes don't fast forward the remote. Yes, but you will have to do a merge at some point, right ? While I'm keeping a purely linear history (not that it is good in the general case, but for "projects" on which I'm the only developper, I find it good. For example, my ${HOME}/etc/). But don't get me wrong, I also prefer the decentralized way in most case. And I'm happy that bzr and git work like this by default. Just that at least *I* have cases where a centralized approach suits me better, and then I'm happy with that particular feature of bzr. -- Matthieu - 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