Reinhold Kainhofer <reinh...@kainhofer.com> writes: > Am Sonntag, 22. November 2009 07:49:04 schrieb David Kastrup: >> Carl Sorensen <c_soren...@byu.edu> 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 _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
