Re: What is missing from Git v2.0

[Jonathan Nieder <jrnieder@gmail.com>]

Hi,

David Kastrup wrote:
> Javier Domingo Cansino <javierdo1@gmail.com> writes:

>> = Reject non-fast-forward pulls by default =
>> Not having this introduced yet allows newbie people to use git with
>> just 4 commands, without bothering around with fetch and merge and so.
>
> If you have a gun lying around your house, you should turn the safety
> catch off or the children will not be able to use it without
> instruction.

I probably missed a subtlety, but the above comment reminded me of
some netiquette I think this list is starting to forget.  If I have
misread it, please let me know and skip the rest of this message.

This is a comment about style, not substance.  Like coding style,
discussion style matters as a way of making life easier for
maintainers and new contributors, and different projects have subtly
different practices.

On the git list, the rule is simple.  Feel free to grumble, but make
sure there is some contribution in the same message.  For example,
after the confusing gun analogy you can say "How about this patch?"
and people reading can follow up by reviewing that patch and
potentially getting it applied.

"But what if there's already a patch doing what I want to do?" you
might ask.  No problem.  Link to the patch and say "I think this patch
should be revisited", or even better, re-send it with some notes about
how previous review comments have been addressed or remain to be
addressed.

"How do I get feedback on design of a new change without wasting a lot
of time coding something that might be a bad idea?"  Glad you asked.
Sometimes instead of a patch, a better contribution is a detailed
explanation of a design to be reviewed and adopted.  In this case, do
try to be clear about whether you'll have enough time to implement the
result or will be relying on others so people know how much time to
devote to working out the details.

"What about feature requests?  I might have an idea for improving git
that no one's had before but I don't have a detailed design in mind."
Sure, that can be a good contribution.  Just treat it as a gift ---
don't assume anyone is going to implement it for you if they're not
interested.

"What about reminders about known bugs?  There's this regression and
it would not be right to release without fixing it but I think it's
fallen through the cracks."  Yes, good contribution.

"What about jokes?"  Sure, making people laugh is productive.

"What about cryptic grumbling?"  Sorry, unless you are grumbling to
get input on how to improve git's documentation or code, it's not
enough to be worth sending an email to this list.

Hope that helps,
Jonathan