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