Re: [boost] [git] neglected aspects

Subject: Re: [boost] [git] neglected aspects
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2012-02-11 11:04:28

Julien Nitard wrote:

>> No, there is a fundamental difference between svn and git. Let me
>> elaborate.
>> 
>> In svn, by "branch" we just mean a branch of the file tree in the
>> repository. The repository as a whole has a single history which is a
>> linear sequence of revisions. So of course you can make a feature
>> branch, but a commit to that feature branch is really also a commit to
>> all other branches, the trunk and all tags -- and vice versa.
> 
> This is just wrong. A commit (or revert) to a branch is a commit to
> that branch only. And don't tell me that the shared version number is
> a problem.

Of course I may be wrong. Please help me to clarify: if I checkout 
branch A (only) and commit a change to it and branch B is not affected 
along the way, is that because (1) I didn't edit branch B, so 
naturally it wouldn't be affected, or (2) svn somehow treats edits on 
branch A as events that are isolated from edits on branch B?

The latter would mean that svn could, for example, prevent me from 
doing the following: checkout the entire /branches directory, make 
edits on both /branches/A and /brances/B, then commit all changes 
together in one revision.

>> If at
>> second thought you don't like your last three commits to the feature
>> branch, you can't just revert history because that might also undo,
>> say, the last twenty commits other people made to trunk. So you always
>> have to manually select which files or subtrees to revert.
> 
> You're wrong, again. This is completely possible and even simple. I
> only have to select (including cherry picking) the commits I want to
> revert.

So if I checkout branch A (only) and I say "svn revert 2", only the 
files in branch A will be affected because svn understands that I'm 
not working on other branches. Is that what you're saying?

Yes, basically that means I'm wrong. However I want to ask you how svn 
is doing this. Personally I think history stays as it is -- say at 
revision 3 -- but that svn replaces the files in my working directory 
with those from branch A at revision 2. Next I can edit those files or 
commit them straight away, which would produce revision 4.

A reset in git is different: you undo history rather than retrieving 
files from an old commit. I'm still inclined to think that if there 
was such a thing as undoing history in svn, it would always affect the 
entire repository rather than just your working branch.
Note that if I'm right (but again, I might not), git also has a revert 
operation, which lets you retrieve files from an old commit without 
affecting history.

One final note: if I run "svn help revert", it does seem to need a 
path as an argument, and it also says it isn't able to restore deleted 
directories. To me, that seems strictly less powerful than a git 
reset.

> The level of wrongness in this email (at least the quoted part above)
> is such that it is hard for me to keep calm. I am, admittedly, biased
> toward SVN. I can accept that DCVS systems like git may improve the
> workflow on projects like boost, but you're twisting facts. I am
> currently wondering whether you did that on purpose or not.

Please take my word that I didn't intend to give misinformation. I 
made an error because I went a little too quickly over the issue and 
failed to realise that a reset in git is a different beast from a 
revert in svn.

I might have made other errors as well, which would also be 
unintentional, but that's still open to discussion for as far as I'm 
concerned.

> Sorry if this was too strong, I am not perfect myself and make
> mistakes too.  I would like to keep the discussion in a cordial tone
> if possible.

It's ok, nothing personal, I like a cordial tone too. 

-Julian