Re: [RFC/GSoC] Introduction

> On Sun, Mar 13, 2016 at 10:25 PM, Sidhant Sharma <tigerkid001@gmail.com> wrote:
>> On Monday 14 March 2016 04:58 AM, Jacob Keller wrote:
>>>
>>> If I recall correctly, a configuration setting was previously
>>> discussed but mostly discarded as a solution since any changes had
>>> better not impact any current scripts. Having to add "--no-beginner"
>>> for all of them seems unacceptable. Especially since many scripts may
>>> do potentially dangerous operations in a safe or useful way.
>>>
>> I agree that adding `--no-beginner` to all such commands wouldn't be right. In
>> that case, can we have the flag between git and the command? Such as
>> `git --no-beginner reset --hard`. If present, the flag can then be removed from
>> the argument list and the rest of the command executed as is without warning.
>> Would that a better option?
>>
>>
>> Thanks and regards,
>> Sidhant Sharma
>>
> No, the whole problem with "--no-beginner" is that scripts must either
> check the configuration variable or add the flag. Since, by definition
> exactly zero scripts do that today, then every script must either (a)
> be re-written, (b) accept that some behavior will not work as
> expected.
>
> Most (robust) scripts will already check for aliases, and if not, the
> user should expect that doing weird things to their environment in
> this way would cause things to break.
>
> I don't think we can create a design where scripts must be re-written
> to protect themselves or accept misbehaving in those ways.
>
> If we had a clear (used) delineation between porcelain and plumbing
> commands, we could have all the porcelain commands accept an argument
> but not plumbing. Except that (a) all plumbing commands can be called
> from the path relatively easily so a user might still want protection
> on those too and (b) we don't actually have an enforced
> plumbing/porcelain distinction. While we document one, several scripts
> exist in the wild which violate this and which we may want to support.
>
> I think that we could go this route, but we'd have to be willing to
> accept (a) or (b), above as costs to this route. Personally I prefer
> the wrapper approach since it neatly bypasses all of this behavior and
> seems easier to implement.  It's major downside is telling beginners
> to use "ggit" or similar, which is a big deal.