On Fri, Jun 2, 2017 at 8:00 AM, Boris Zbarsky <bzbar...@mit.edu> wrote:
> 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? > IIRC the culture around length limits is mostly a cargo cult. If you squint hard enough, you can trace the origins of these line limits to: * The prevalence of email to exchange patches (like Linux, which is what Git was invented for) plus the fact that some email encodings wrap long lines * IBM punch cards having 80 columns (this was later carried forward to TTYs and has been cargo culted through subsequent decades) In other words, the [short] line limits or not relevant to many modern workflows. It is unfortunate tools like GitHub are participating in this cargo cult. As someone who spends a lot of time writing tools, I really despise when tools dictate implementation details: tools should be subservient to their users, not the other way around. > > 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. > > 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 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. I agree you are in kind of a bind here because you probably aren't going to convince GitHub to change their UI. However, I believe the full commit message is in the DOM. At least it is for the example in the original post. I'm sure someone could come up with a WebExtension or Greasemonkey script to hack the UI to show what you want. I wouldn't be surprised if someone already has! Also, we don't have these "lack of control over tools" problems with hg.mozilla.org. While the UI isn't as clean as GitHub's, we don't truncate the commit message. And where it is appropriate, we also supplement views with relevant metadata, such as links to bugs, reviewer name, link to automation results, etc. See https://hg.mozilla.org/mozilla-central/rev/ 39e5304d676d for an example. You may find the https://hg.mozilla.org/projects/converted-servo-linear repo useful: it is all the changesets comprising the servo/ directory in mozilla-central before they are overlayed into mozilla-central. But it has all the merges collapsed. If a straight conversion of the Git repo to Mercurial (so you aren't crippled by GitHub's UI) would be useful, I've created a one-off at https://hg.mozilla.org/users/gszorc_mozilla.com/servo-git-conversion. If you want it done in a more formal manner (ongoing conversion, links back to GitHub, etc), it shouldn't be too much effort. File a Servo VCS Sync bug. While I'm advocating for the benefits of the Mercurial web UI, that search box in the top right is useful. It accepts many Mercurial revset functions ( https://hg.mozilla.org/mozilla-central/help/revisions). This means you have a query language and can type things like |file("components/layout/**") & reviewer(bholley)| to perform powerful searches. Again, we have full control over that UI, can implement custom query functions, and can easily submit patches to upstream Mercurial. So if something will make your life easier, please ask for it by filing an hg.mozilla.org bug. _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
