On Mon, Mar 16, 2015 at 3:54 PM, Eduardo A. Bustamante López <dual...@gmail.com> wrote: > I know that some people are interested in a more detailed commit history in > bash's git repository. After all, it's easier for all of us to just learn to > use a tool, and use that for everything.
How are you planning on creating a more detailed commit history than the history that's already there? You're going through the changelog and guessing about how code changes map to certain changelog entries? I'm not sure how well that can work. I've thought about ways to improve the situation but I'm not sure about how to improve commit detail when almost all the changes come in periodic code drops. You would have to do a lot of guesswork. Starting with a better workflow now is certainly possible. There should ideally be a stable branch for each stable release (4.0, 4.1, ...) forked from master from the correct points. Development of patch releases should of course be done in their own branches and merged into stable branches. New features would ideally have per-feature branches that get merged to master rather than a single "devel" branch that tends to be way ahead of master. Maybe you have better ideas. It's probably best to do whatever you plan on your own branch if possible. -- Dan Douglas