Hi - If you run 'git log', you can see that most of these 'Merge' commit messages don't have good line wrapping.That makes it very awkward to use 'git log' to view history. See
http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html to understand what is a good git commit message. (but I think we probably already know that). Also the commit messages like 'Merge pull request #bla from user/branch' is not really useful in summary form (likewhen you do git log --pretty=short for example) I know that we've been trying to put an overall commit message (like the old SVN commit message) into the Merge box on the GitHub website in order to have a high-level view of the commit history, in case the local git commits add a lot of noise. An alternative approach would be to ask everybody to use 'git rebase -i' to make tidy history before making their commits (I got used to doing that in order to make SVN-ready patches). But, I acknowledge that rebasing can add some complexity... Also, if you use the command line merge option described on GitHub, you have the ability to change the subject (which really should be something like the overall topic in my view) and to make sure that you're line-wrapping right (by using a usual text editor). What I don't know is if there isany reasonable way to instruct the GitHub web pages to help us line-wrap these messages better or to let us edit the subject line. (If we can't change the Merge pull request ....' part, maybe at least we could be more careful about naming our branches, and then make the 2nd line always be a useful topic?) I'd vote for: - basically tidy history beforedoing merge requests; each commit contains at least a good subject line for that change and hopefully a description - merge log message always including the topic and including overall details and reviewer etc; and also including overall description if there are multiple commits in the merge or if the individual commit history is not adequate. (I don't know if doing that would prevent GitHub from linking merge commits to pull requests, or if it's possible to use this strategy at all on the web site). The best online reference I've found for best practices is: http://codeinthehole.com/writing/pull-requests-and-other-good-practices-for-teams-using-github/ Thanks, -michael ------------------------------------------------------------------------------ Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk _______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
