Sean  writes:
> On Tue, 17 Oct 2006 13:19:08 +0200

quoted text
> Matthieu Moy  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

quoted text
>>    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

quoted text
>> "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

quoted text
>> 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@vger.kernel.org

More majordomo info at  http://vger.kernel.org/majordomo-info.html