Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)

[Felipe Contreras <felipe.contreras@gmail.com>]

On Thu, Apr 18, 2013 at 4:19 AM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> Felipe Contreras wrote:
>> I think the commit message is fine, you don't. So YOU go ahead and
>> write the proper one. If you don't, all you are doing is being an
>> impediment to progress.
>
> Hey Felipe.  Let's get a few things straightened out first:
>
> - We all act in our selfish interests, and write code to scratch our
> personal itches.  I don't write code or commit messages for anyone
> else, and neither should you.
>
> - However, we're not working in isolation.  We have this giant mailing
> list where we all post our patches.  It's like a bazaar where we
> compete against other patches for developer attention and potential
> reviewers.  In other words, it's a free market, and we're selling our
> product: if it fails to sell, will you blame the market or your
> product?  I write clear code and beautiful commit messages exactly for
> this reason: I'm fighting for attention!

Except the customers are not git developers, it's git users. Git
developers rejecting patches because of the commit message is akin to
distributors rejecting products because they don't like the
transportation packages; they are only hurting themselves, by hurting
their customers.

> - We have to learn to interoperate with others' code and conventions,
> if we want to be part of the community.  That doesn't mean that we
> drown out our individuality, but it means that a our patch series has
> to conform to some minimal, loose, and evolving standard.  Now, you
> can argue that many of the existing conventions are outdated (I do it
> all the time), but it cannot change overnight.  Your influence on the
> community will show up over an extended period of time.

And the only way it can change is by discussing.

The only one that gets bitten by fixes not getting merged are git
users, not me. So if a discussion of a commit message impedes the
merging of the commit, I don't get affected, but when we have agreed
to disagree on what constitutes a good message, and the patch is still
on hold, then there's a problem.

> - We are not an old enterprise who blame breakages on a few
> individuals, and fire them.  We're a community where all of us are
> equally responsible for all parts of the code.  I am as responsible
> for the remote-hg code in master as you are, as I had every
> opportunity to review it when the patch series came up on the list.  I
> might have chosen not to, but that doesn't relieve me of
> responsibility.

I don't think so. Unless you added your Signed-off-by, you are not.

> -  We don't practice division of labour.  There are no managers,
> "testing people", "documentation people", "code-writing people",
> "commit-message writing people" etc.  Everyone has to do some portion
> of all these tasks, although we try to keep the boring work/ technical
> debt to a minimum.  Don't ask other people to write commit messages
> for your code.

I am not. Neither should they ask me to write the commit messages they
want. They can make *suggestions*, and I can reject them.

When two persons have different ideas, often times both are wrong, and
the middle-ground is best, but sometimes a person reaches the
middle-ground, and sometimes one person was right from the start.

But when everyone shares the *assumption* that there is never a commit
message that is too long, you know the wrestling mat of ideas is
rigged. I wonder if I should write a commit message as long as a book
chapter for a one-liner, only to prove a point, but I'm honestly
afraid that it would be committed as is.

And remember what started the conversation; do you think a patch with
a possibly incomplete commit message should not be merged to pu
(proposed updates), shouldn't even be mentioned in the "what's
cooking" mail, and thus shouldn't even be considered "cooking"?

Cheers.

-- 
Felipe Contreras