Re: [RFC/PATCH] git put: an alternative to add/reset/checkout

From: Junio C Hamano <gitster@pobox.com>
To: mike@nahas.com
Cc: Nguyen Thai Ngoc Duy <pclouds@gmail.com>,
	Jeff King <peff@peff.net>,
	git@vger.kernel.org, Scott Chacon <schacon@gmail.com>,
	Jakub Narebski <jnareb@gmail.com>,
	Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Subject: Re: [RFC/PATCH] git put: an alternative to add/reset/checkout
Date: Mon, 23 Jan 2012 10:10:57 -0800	[thread overview]
Message-ID: <7vaa5e9tn2.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <CADo4Y9j5MwKr+rWza0ncLWuthY6x+s68CQYbY2+c8-E5pAa=Sw@mail.gmail.com> (Michael Nahas's message of "Mon, 23 Jan 2012 09:56:37 -0500")

Michael Nahas <mike.nahas@gmail.com> writes:

> It obviously isn't the design-first-then-find-a-willing-programmer of
> the project I ran. I don't know if it's the IETF's "running code and
> a general consensus".

These two are not necessarily incompatible.

A proposed new feature needs to be explained well, describing in what
situation it will help what kind of users and without hurting others and
why it is a worthy addition.

We require a general consensus that any proposed change is a worthy
addition, and a working code is often a good addition to help us reaching
one, because people can guess what is being proposed even when the idea is
presented poorly. A poorly presented idea without working code often fares
no better than just a handwaving with crazy talk, as you fail to make
others realize what you are trying to achieve.

But working code is not a requirement to present good ideas. It just helps
to add clarity to it.