Good point about the line wrapping, I hadn't noticed it. Interestingly, looking through the most recent commits, it seems to vary a bit across commits -- many have very long (or even just slightly-too-long) lines, while others (typically longer messages) are better formatted for 80-cols. I wonder if this could be a "type the message in the github window" vs. "type it in emacs and paste it in" difference?
Not that I'm suggesting that this is the right solution, but I'm noticing that the variant of 'less' that 'git log' uses supports the arrow keys as a way to "scroll over" and read longer lines. Oh, I meant to mention it before, but I'm also finding --reverse very helpful in reading git logs in chronological order (of course, using the commands I gave below, it starts from the beginning of time for better or worse). -Brad ________________________________________ From: Michael Ferguson [[email protected]] Sent: Thursday, August 07, 2014 8:06 AM To: Brad Chamberlain Cc: chapel-developers Subject: Re: [Chapel-developers] merge messages Hi - Cool! I find that git log -m --first-parent --stat helps a lot but I still want the pull request merge message to be more line wrapped. That command makes me less worried about the commit history within the pull request (but we surely need to update doc/developer/bestPractices/GitCheatsheet.txt with it). Of course, we're all getting used to this... Best, -michael On 08/07/2014 11:03 AM, Brad Chamberlain wrote: > 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
