Re: GSoC 2016: applications open, deadline = Fri, 19/2

[Lars Schneider <larsxschneider@gmail.com>]

On 18 Feb 2016, at 20:13, Junio C Hamano <gitster@pobox.com> wrote:

> Stefan Beller <sbeller@google.com> writes:
> 
>> On Thu, Feb 18, 2016 at 12:41 AM, Lars Schneider
>> <larsxschneider@gmail.com> wrote:
>>>> Feel free to start writting an idea for
>>>> http://git.github.io/SoC-2016-Ideas/. It'd be nice to have a few more
>>>> ideas before Friday. We can polish them later if needed.
>>> 
>>> I published my ideas here:
>>> https://github.com/git/git.github.io/pull/125/files
>> 
>> I like the idea of a beginner mode, but on the other hand that looks
>> inflexible to me ;)
>> (What if I want to use rebase, but not reset --hard?)
> 
> That's simple.  You say "cd .. && rm -fr repo && git clone" and
> start from scratch ;-).
> 
> This whole "beginner should be limited to a 'safe' subset" is an
> unhealthy attitude.
> 
> Deciding what the 'safe' subset is must be done with a lot of
> thinking by people who intimately know what implications it has to
> ban each feature.  I do not think it would be a good fit for a
> project to give to a relatively new participant to the Git project.
> 
> For example, I think banning "worktree" feature from newbies may not
> be a bad idea, as you can work on a project without using "worktree"
> at all, and use of "worktree" would only subject you to bugs that do
> not exist when you do not use that feature.  The "shallow clone",
> "sparse checkout", and "untracked cache" fall into the same category
> for exactly the same reason.  The "submodule" feature might fall
> into the same category for the same reason, but that is not
> something you as a project participant can unilaterally decide, as
> the project you are working on may have already decided to use the
> feature, so it is harder to ban from the beginners.
> 
> But for the rest of really "core" part of Git, I do not think there
> is any such command that can be totally banned.
> 
> We have these "powerful" tools for a reason.  After making a mess
> experimenting with your working tree files, "reset --hard" is the
> best tool to go back to the known-good state, and robbing it from
> the users is not a sound approach to help them.  When "powerful"
> becomes "too powerful" is when a "powerful" tool is misused.  It is
> perhaps done by mistake or perhaps done by copying and pasting a
> solution from Interweb for a problem that does not match your
> situation without understanding what you are doing.
> 
> What is needed to help beginners is to make the powerful tool harder
> to misuse.  Of course, that would be a harder task, because you have
> to do a real thinking.
> 
> You do not have to do any thinking to say that "a blanket ban that
> hides these powerful tools behind the beginner mode" helps
> beginners, but I do not think it is solving what really matters.  At
> the same time, it just adds to the FUD, i.e. some commands are too
> powerful for their own good.

Thanks for your elaborate response. I think I got your point and I
tried to adjust my "beginner mode" proposal accordingly [1]. Here
is the relevant change:

If this mode is enabled then Git shall print a warning message before 
running a potentially destructive command. In addition to the warning 
Git shall print a command that would reverse the operation if possible. 
Most of the information to reverse an operation is already available 
via git reflog. However, the task here is to make this information more 
easily accessible to Git beginners.

--

Does this go into the direction of "making the powerful tool harder to
misuse"?

Thanks,
Lars