[LLVMdev] [cfe-dev] Commit message policy?
Robinson, Paul
Paul_Robinson at playstation.sony.com
Fri Mar 6 16:08:47 PST 2015
> -----Original Message-----
> From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu] On
> Behalf Of Mehdi Amini
> Sent: Friday, March 06, 2015 1:49 PM
> To: Davide Italiano
> Cc: Clang Dev; LLVM Dev
> Subject: Re: [cfe-dev] [LLVMdev] Commit message policy?
>
>
> > On Mar 6, 2015, at 1:36 PM, Davide Italiano <davide at freebsd.org> wrote:
> >
> > On Fri, Mar 6, 2015 at 1:12 PM, Renato Golin <renato.golin at linaro.org>
> wrote:
> >> On 6 March 2015 at 20:59, Reid Kleckner <rnk at google.com> wrote:
> >>> I think the only guideline we should have is that the first line
> should be
> >>> written as though it is an email subject, because it gets used for
> that. If
> >>> you write a long first line, then you get a long subject, and it looks
> >>> silly. If people want to embarrass themselves with strangely formatted
> >>> email, they it's on them. We don't need a specific hard or soft
> number.
> >>
> >> Not many people care about the email subject already, that's why they
> >> keep using ridiculously long first lines.
> >>
> >> IMO, "suggesting" to write short first lines is the same as not doing
> >> anything. Either we add a cap (say, 80 chars), or we don't do
> >> anything.
> >>
> >> Chandler's other suggestion, tough, is interesting: to write up a bit
> >> about what a *good* message would be, so the people that were really
> >> interested, could do it "right" (tm).
> >>
> >
> > Another guideline I would like to propose for commit messages is that
> > of attaching to the commit a link to the code review, if any.
>
> I believe it is documented here:
> http://llvm.org/docs/Phabricator.html#committing-a-change
>
> Mehdi
That would be the norm for people doing reviews in Phabricator.
I think the suggestion is to do something similar for non-Phab reviews?
--paulr
>
>
> > For big
> > changes, this allows easily to reconstruct the history of the commit,
> > together with other informations (e.g. the reviewers). A potential
> > downside of it is that links might be not valid anymore after a while,
> > but I still think the advantages overcome the problems.
> >
> > FWIW, I already try to include this info when I commit, so if it's not
> > OK or people have concerns about it, I would like to have this
> > explictly stated.
> >
> > --
> > Davide
> >
> > "There are no solved problems; there are only problems that are more
> > or less solved" -- Henri Poincare
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
More information about the llvm-dev
mailing list