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
>> 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
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
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
> 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
> 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.