Hi Michael -- I don't have the experience or knowledge to weigh in on this in great detail other than to say that I hear where you are coming from. I will pass along some helpful 'log' commands that Thomas sent me to get something closer to what I was used to in the SVN world (though I think they still get prefixed with the auto "merge pull request" first line for better or worse. I'm trying to recall -- with care can one not edit that line out of the commit of the pull request? i.e., is it simply a default that we could change with minimal effort, or are we stuck with it?)
Anyway, here's Thomas's information. He writes: --- To get rid of the merges that are not to master, so you only see the interesting pull request merges, use: git log --merges --first-parent And actually, this is the ³all pull request merges and all the original svn trunk commits² view you are looking for: git log --first-parent And if you wanted to include files changed: git log -m --first-parent --stat Or for something similar to the svn files changed: git log -m --first-parent --name-status ---- Michael, I think the discussion so far has been not to rebase/compress the pull request before submitting it because the theory was that having the full commit history that was done in preparing the patch was useful information (similar to how, on SVN, when we did do things on branches, we merged that history into trunk rather than just merging the final snapshot). The above aliases make this seem tractable to me from a "surfing the history" perspective (with the caveat that I don't have a lot of experience yet). I think there's more discussion that should go on here, I just don't have the experience yet to say much more than this myself (and am on the road this week). -Brad ________________________________________ From: Michael Ferguson [[email protected]] Sent: Thursday, August 07, 2014 7:24 AM To: chapel-developers Subject: [Chapel-developers] merge messages 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 ------------------------------------------------------------------------------ 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
