Jonathan Nieder <jrnieder@xxxxxxxxx> writes:
> Hi,
>
> David Kastrup wrote:
>> Javier Domingo Cansino <javierdo1@xxxxxxxxx> 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.
Uh, Javier was commenting on a number of concrete proposals regarding
the subject line "What is missing from Git v2.0" and quoted Felipe
directly. As you seem to have lost the context, let me requote the
respective portion:
From: Felipe Contreras <felipe.contreras@xxxxxxxxx>
Subject: What is missing from Git v2.0
Newsgroups: gmane.comp.version-control.git
To: git@xxxxxxxxxxxxxxx
Date: Sun, 20 Apr 2014 17:41:05 -0500 (4 days, 17 hours, 12 minutes ago)
[...]
= Reject non-fast-forward pulls by default =
Many new-comers end up making merges by mistake when they pull
because they don't understand what is a non-fast-forward and what
they should actually be doing. Most people, even Linus Torvalds,
agreed that by default `git pull` should fail and guide the user,
instead of silently making a merge which might not be what the user
wants (even though he doesn't know it), and messing up the project's
history, which affects other people.
The patches were sent, the issues were addressed, people agreed, and
yet nothing happened.
[3][4]
[...]
[3] http://thread.gmane.org/gmane.comp.version-control.git/240030
[4] http://thread.gmane.org/gmane.comp.version-control.git/235981
> "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.
I didn't.
> "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,
No need to get condescending if you did not get the joke.
--
David Kastrup
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html