> Le 2 juin 2017 à 17:00, Boris Zbarsky <bzbar...@mit.edu> a écrit : > > On 6/2/17 5:18 AM, Anthony Ramine wrote: >> In the following screenshot, you can see one doesn't even know what that >> commit is supposed to do from its title, because it is way too long to be >> informative. > > OK, what is the proposed cap on first line of commit message? > > Everything I've seen suggests the first line should be a one-sentence simple > summary of what's going on. The fact that github insists on cutting it off > to pretty short lengths, shorter than most sentences, is a bit unfortunate.
Everything I've seen suggest the first line to be a *short* sentence, Git itself recommends it, and Github truncates because of this reason AFAIK. https://git-scm.com/docs/git-commit > Though not required, it’s a good idea to begin the commit message with a > single short (less than 50 character) line summarizing the change, followed > by a blank line and then a more thorough description. The text up to the > first blank line in a commit message is treated as the commit title, and that > title is used throughout Git. For example, git-format-patch[1] turns a commit > into email, and it uses the title on the Subject line and the rest of the > commit in the body. http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html https://github.com/erlang/otp/wiki/Writing-good-commit-messages (wink wink) https://github.com/git/git/blob/master/Documentation/SubmittingPatches#L95-L99 > Or concretely, what would you say one should use instead of "Being affected > by id selectors should not prevent an element from being inserted in the > style sharing cache" as a first line? I see two separate issues with that title: it doesn't describe the change, but what was wrong before it, and it is indeed rather long. Not knowing what the actual patch is about, here are a couple suggestions: - Fix style sharing of elements affected by id selectors - Share styles of elements affected by id selectors (only?) >> I also want to argue that the very "bug X - " prefix is counterproductive in >> Servo commits > > If we don't propagate those servo commits as separate commits to the Gecko > side, then I agree. I've just been putting the full bugzilla link in the > non-first line of the commit message. Links are good, thanks. I don't particularly mind the actual bug numbers, I just think they would be easier to ignore (and would waste less screen estate) if they were added as suffixes of the commit title. _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
