← Back to team overview

maas-devel team mailing list archive

Re: commit messages

 

On Thu, 30 Aug 2012, Gavin Panella wrote:

> On 29 August 2012 13:56, Scott Moser <smoser@xxxxxxxxxx> wrote:
> > [bug=] NodeGroups update_leases API call.
>
> On Launchpad, since 2007/2008, we probably would have phrased the
> above like:
>
>   Introduce update_leases API call, so that cluster controllers can
>   push DHCP lease information to the region controller. Previously
>   this was being done by splicing a base4 representation of the leases
>   into a chicken's DNA and encouraging it to cross the road.
>
> The longer description would remain in the merge proposal.
>
> I like this. The merge proposal description is for a small audience at
> a particular moment, and as such I can assume some context. A commit
> message is for posterity and so requires more care to craft. I don't
> read commit messages enough to be convinced that the effort is worth
> it.

I read commit messages all the time. Anything else is needlessly far away
from me.  If I don't have network connectivity, then anything in launchpad
is completely useless, if I *do* have network connectivity, its still much
slower than 'bzr log' and I have that same "hacker lazy" problem.  I want
a full explanation of why code changed in the most easily accessible
place.

I'd love to have commit messages like you stated above.  If you write a
nice description for the merge proposal, why would you *not* want that
copied to the commit message.

If you're annoyed by longwinded ness in 'bzr log', that is fixed in the
git world by just specifying a short 1 line summary followed by a blank
line, followed by the longwinded description.

Tools know about that convention so 'git log --pretty=short' gets you the
short summarys.

> Is this an acceptable middle-ground Scott? I have no objections if you
> or anyone else wants to write longer commit messages. I'm just being
> hacker-lazy.
>

I admit that it is probably un-familiarity with launchpad that is
prompting this.  But I am just *way* to lazy to:
 bzr blame
 bzr log
 # find merge proposal in there somewhere in bzr metadata, I suspect
 # that the merge number is in there somwhere, but I don't see it.
 xdg-open <that-url>
 read detailed summary

I'm really baffled as to why you wouldn't want that in the commit message.
>

Follow ups

References