Merging to the release_1_6 branch
raimue at macports.org
Tue May 27 13:38:01 PDT 2008
Caspar Florian Ebeling wrote:
> This is exactly what I have been preaching, but I think it changes
> with Git. I know that saying this might well be boring by now, but Git
> eases the whole branch handling a lot. And svnmerge.py is really
> not a substitute here. I used it for a feature branch of a project and
> some file renamings made things go haywire. It was certainly not
> the reassurement your actually want to get out of version control.
Git is just another version control system and does not decide if we
make feature branches or not. Yes, merging in Subversion is not the
best, but this will become a lot better with Subversion 1.5. I don't
think we have to discuss different version control systems and their
advantages here. Basically, they are all the same. You got a main line
and branches. So we have to decide how to use branches, not which system
stores our branches.
Jordan brings up the idea not to use branches at all, but to make
releases from the main line. I don't agree that this would be sane, even
if it comes from his experience. How would we do minor releases for
bugfixes without branches? I can only think of checking out the tag,
applying (multiple?) patches and creating a new tag from it. Which would
not give you any control to see what you applied and you would also need
to apply that separately to the main line without any connection between
the two commits! Gosh.
I really don't think we want to do it this way.
> But git mostly makes branches a private thing, so that effectively
> their number rather gets reduced, or at least the number of public
> ones gets reduced. The existing branches tend to be feature-specific,
> and mainline
> stays sane because branches only get merged in once they are
> not questionable anymore.
So who tests your new code? You privately and nobody else? And you never
test it together with other features which could even break it? Doesn't
sound like a good idea to me.
More information about the macports-dev