Re: What is missing from Git v2.0

From: David Kastrup <dak@gnu.org>
Date: Apr 25, 2014, 15:59 UTC
Message-ID: <871twl9z8h.fsf@fencepost.gnu.org>
In-Reply-To: <20140425154104.GB11479@google.com>

Jonathan Nieder <jrnieder@gmail.com> writes:

Show 27 quoted lines

> 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.

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@gmail.com>
    Subject: What is missing from Git v2.0
    Newsgroups: gmane.comp.version-control.git
    To: git@vger.kernel.org
    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.

Show 11 quoted lines

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