On Sat, 7 Jun 2008, Robert Anderson wrote: > On Sat, Jun 7, 2008 at 2:22 AM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: >> rwa000@xxxxxxxxx (Robert Anderson) writes: >> >>> From 7af03a835b7311c501f2147e25f428642fc3acb7 Mon Sep 17 00:00:00 2001 >> >> FYI this line is not necessary, and should be removed from >> git-format-patch output when pasting it to your MUA. > > Err, then shouldn't it be removed from format-patch, rather than > deleted manually every time format-patch is used? It is needed, I think, for git-format-patch output to be in mbox format, so you can just send it (for example using git-send-email), or make your MUA open it. If you copy'n'paste, or equivalently use "insert file", into body of your message, this is not necessary and should be removed. >>> From: Robert W. Anderson <rwa000@xxxxxxxxx> >>> Date: Fri, 6 Jun 2008 23:53:37 -0700 >>> Subject: [PATCH] improve doc heading for git-bisect >> >> FYI the above isn't strictly necessary: if you have 'From:' header set >> correctly you can simply set subject of email, and put in body the >> rest of commit message and patch only, without extra mail-like >> headers. > > Then remove them from format-patch, IMO. Well, the "Subject:" is neede to copy it to the email subject line in your MUA. If from differs from the account you send email from, it should also be set or left in the body of message. Besides, there are two conventions of sending patches to git mailing list, used in slightly different circumstances. 1. Put "Subject:" in the email subject line, remove all headers, put comments to patch (those which do not belong in commit message itself, for example how the patch differs from previously sent version, etc.) between "---" and diffstat. 2. In the case when patch is response to longer thread, or the message body is much longer than commit message, you have the comments to patch or further part of discussion at beginning, then some kind of marker e.g. "-- >8 --" (scissors), but NOT "---" to mark beginning of commit, then commit message, including From: and Subject: lines. In short: this information is sometimes needed. >>> Improve awkward heading in git-bisect documentation. >> [...] >>> -Avoiding to test a commit >>> -~~~~~~~~~~~~~~~~~~~~~~~~~ >>> +Changing the revision to test >>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >>> If in a middle of bisect session, you know what the bisect suggested >>> to try next is not a good one to test (e.g. the change the commit >> >> It is, I guess, better, but is it the best heading? What we want to >> describe here is how to deal when bisect stops on commit which cannot >> be tested (e.g. project does not compile). > > I disagree. The situation you want to use this is more general than > that. Maybe you could test it, but doing so would be a waste of time > because the commit is a trivial comment change. In general, this > simply what you need to know when you want to change the revision > under test. Well, I don't have better idea on how to write short but precise header, and your change is certainly better... -- Jakub Narebski Poland -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
