On Fri, May 13, 2011 at 3:25 AM, Tom Bachmann <[email protected]> wrote: >>> >>> The problem is that it leads to tons of (trivial) merge conflicts. Say >>> both >>> you and me add some small feature, and write it to the end of the >>> changelog. >>> Then whoever gets pushed in second will have a merge conflict. Sure, it's >>> simple enough to fix, but it's going to happen every single time (then >>> again, maybe git is smart enough to handle it automatically, I don't >>> know). >> >> I'm not sure how well it does with that. The auto-merging tends to be >> for code that is completely separate (all the diff including the >> context is the same). >> > > Keeping a separate changelog in the revision control is definitely a bad > idea. > > 1) If it's a proper changelog, then it is mostly going to replicate the git > changelog, and we shouldn't do that. > > 2) In any case there are going to be many conflicts, and no merging tool is > going to be able to handle them (unless perhaps we write our own). I > contributed to a few projects that kept proper, separate gnu-style > changelogs and the merge conflicts are *always* there. In fact these project > now use git and just generate the changelogs from git log periodically. > > On the other hand writing a "meta changelog" or releaselog on the wiki as we > go along sounds like a good idea.
Exactly. I also think that having a changelog in the sympy git is not a good idea. Ondrej -- You received this message because you are subscribed to the Google Groups "sympy" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
