Hi, David Kastrup wrote: > Javier Domingo Cansino <javier...@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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
