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

On Thu, Apr 18, 2013 at 5:27 AM, Ramkumar Ramachandra
[off-list ref] wrote:

Felipe Contreras wrote:

quoted

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.

Huh?  I certainly don't develop for some "git users" I don't even know
or care about.  In this order of precedence, my customers are:

1. Me.
2. People who develop git.git, whom I have to cooperate with.
3. People who exercise git heavily like the linux.git community, as
opposed to some little projects that operate using pull requests on
GitHub.
...
137. People who incidentally choose to use git.
138. People who incidentally choose to use git, but aren't on Linux.

As they are for most open source developers on the planet, not me. I
believe a project is nothing without its users.

And nobody is hurting anyone else.  Someone wrote some code, and
failed to sell it to the community.  That's all happened.

If remote-hg wasn't available for users, they would be hurt; if stash
wasn't available, if rebase --interactive didn't exist, if there was
no msysgit, if it wasn't so fast, if the object model wasn't so simple
and extensible; users would be hurt. And if users didn't have all
these, there would be less users, and if there were less users, there
would be less developers, and mercurial might have been more popular,
and most repositories you have to work on would be in mercurial, and
you might be developing mercurial right now.

But I won't bother trying to convince you that no project is more
important than its users (in the words of Linus Torvalds), because
most people don't see the big picture.

quoted

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

Okay, so your view differs.

quoted

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

Ofcourse you have a right to reject suggestions.  The question at the
end of the day doesn't change: did you manage to get people to read
your patch?

No, at the end of the day what matters is: did the users benefit from this?

The answer for this particular patch is no, and it's not my fault.

quoted

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.

https://yourlogicalfallacyis.com/middle-ground :)

Yeah, but I didn't claim that, I said sometimes one person was right
from the start, no middle-ground.

quoted

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.

I'm with you, and don't share that assumption.

s/everyone/almost everyone/

I'm not accusing you
of writing commit messages that don't conform to some "transcendental
standard" either: I didn't look at your patches in the first place,
because the simple Signed-off-by: one-liner in the body didn't really
make me want to read it.

quoted

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"?

It's irrelevant what I think or others think.  The point is that it
wasn't mentioned.  Now, why wasn't it mentioned?  Is it because Junio
and the community hate you, and are conspiring against getting your
code merged?  Or is it because it didn't catch anyone's eye, and Junio
was waiting for it to happen (as always)?

My abridged version of the story is: because Jeff King pointed to an
area of improvement he wasn't even strongly attached to, I agreed to
resubmit, Junio saw that, then I changed my mind, Junio probably
didn't see that, and then he forgot about it.

Then, since it's taboo to suggest that a concise commit message is
fine, a discussion sprung.

TL;DR version: Your goal in submitting a patch is to sell it to other
people in the community.

I disagree.

If enough people like your patch, it gets
merged (but that is only the second step).  Your goal is not to fix
problems for some unknown "users", or argue about some "transcendental
standard".

I disagree.

Ofcourse the community shares some view about what a patch
should look like, but you can mould those expectations gradually.

If experience is any guide, doesn't look like that. But I've noticed
that after many months that a patch has been sent people realize that
it's more important to get the damn issue fixed than to have a hugely
verbose commit message...

Cheers.

-- 
Felipe Contreras