Re: Code review/discussion time again.

[David Kastrup]

Reinhold Kainhofer <address@hidden> writes:

> Am Sonntag, 22. November 2009 07:49:04 schrieb David Kastrup:
>> Carl Sorensen <address@hidden> writes:
>> > And if you have the source tree in a git repository, then it's trivial to
>> > make branches, and checkout the appropriate branch.  That way you don't
>> > have to worry about overwrites (and if you do have overwrite problems,
>> > then you just reset the head).
>> >
>> > It's no problem at all, if you do it that way.
>> 
>> Hello merge conflict, my old friend, I've come to talk with you again...
>> 
>> If you have ever worked in a project with a central ChangeLog file, you
>> know the permanent hassle with switching branches when some changes
>> require entries in a central file.
>
> With git this is not really a problem.

What about "entries in a central file" was not understandable here?

> I'm constantly working with 5-10 different branches. Every now and
> then, I rebase them to current master, but apart from that each branch
> is isolated, doesn't influence each other, and changes to the global
> news file, etc. can be merged when I want to do a rebase.
>
> Really, once you have learned how to use git rebase (and the manual
> merging it sometimes requires), working with branches in git is really
> no problem at all.

Thanks for telling me, but I've been the main feature merger in my last
job for years, using git-svn.

I prefer interface designs not requiring registration in central files.
When you frequently rebase stuff consisting of hundreds of commits, you
don't really want to have a significant percentage of manual merges.

More bluntly: if managing extensions is not feasible without a version
control system, the design is faulty, like a computer that you can't
assemble without a soldering iron.

I _have_ managed computers with soldering iron and hand-wiring.  It is
not merely incompetence when I consider it not the way to go.

-- 
David Kastrup