On Tue, 17 Oct 2006 14:03:21 +0200 Matthieu Moy <Matthieu.Moy@xxxxxxx> wrote: > 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). This is most likely the reason that people using Git don't clammor more for the ability to work without a local repository. Disk is cheap and it just makes sense the vast majority of the time to have a complete copy of the repository yourself. There are a lot of powerful things you can do once you have all that information in your repo. Not the least of which is performing any and all operations while flying on a plane or sitting on a park bench. > 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). Well, with Git the default is to only commit locally. Of course, you could set your post commit hook to always push it to a remote if you wanted to. > 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. Well, it's just a slight difference in perspective rather than any big issue here. Git treats all repositories as peers, so it would never assume that just because one other particular repo has a branch marked as read only that it should be marked read only locally. It lets you commit to it, and then push to say a third and fourth repo that are writable as well. In practice this doesn't really cause any insurmountable problems. > 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/). Well if you're committing changes from multiple different machines, how is that different from having say 3 different developers committing changes to the central repo? How does bzr avoid a merge when you're pushing changes from 3 separate machines? You mentioned that if you try to push and you're not up to date you'll be prompted to update (ie. pull from the upstream repo). When you do such a pull do your local changes get rebased on top or is there a merge? By your comments I guess you're saying they're rebased rather than merged, and this is how you keep a linear history. Git can do this easily, but it's not done by default. Sean - 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