Re: [RFC/GSoC] Introduction

[Sidhant Sharma <tigerkid001@gmail.com>]

On Monday 14 March 2016 11:44 AM, Jacob Keller wrote:
> 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.
Thanks for elaborating on that. I now understand why the configuration
option approach is not fit. The 'ggit' wrapper does sound more
apt for this. I do realize telling the beginners to use 'ggit' instead 
of just 'git' is a shortcoming of this approach, but perhaps it's worth
it if it makes Git easier to use and understand for beginners. Lars'
suggestion of short instructions would be really nice for helping
beginners form a mental picture of git workflow, and might be worth
the trade-off.


Thanks and regards,
Sidhant Sharma