Re: [RFC/GSoC] Introduction

From: Lars Schneider <larsxschneider@gmail.com>
Date: Mar 14, 2016, 08:16 UTC
Message-ID: <FB2E0900-A77E-4AE2-A580-9192746A8ABA@gmail.com>
In-Reply-To: <xmqqk2l58s2a.fsf@gitster.mtv.corp.google.com>

On 14 Mar 2016, at 07:57, Junio C Hamano <gitster@pobox.com> wrote:

Show 26 quoted lines

> Lars Schneider <larsxschneider@gmail.com> writes:
> 
>> I thought a while about this requirement and I wonder if a wrapper called 
>> 'ggit' (guarded Git) could be a solution. The wrapper would pass all 
>> command line arguments to 'git' and check for potentially destructive 
>> commands. If such a command is detected then the user would see a warning.
> 
> I recall back in the days when people said that Hg's command set was
> so much more pleasant to use that some people thought about building
> Hg's command line UI on top of low level implementation of the Git's
> data structure.  Even before that time, there was an effort "Cogito"
> to build an alternate UI on top of Git core.  If "ggit" can be made
> reasonably feature complete in such a way that it lets beginners do
> all what they need to do, omitting many advanced/hairy features core
> Git may let users use (i.e. making trade-off between power and risk
> of misuse differently from core Git), that may be a reasonable way
> to offer a "beginner mode".
> 
> The beauty of such an approach is that as long as "ggit" correctly
> talks the same on-wire protocol when interacting with other people's
> repositories, nobody needs to even know or care that you are using
> "ggit" exclusively.  Two systems can talk without problems.
> 
> If "ggit" is made too limited, there is an issue.  Beginners may at
> some point need to transition to the real thing to fully exploit the
> power of Git, and they may need to unlearn "ggit" and learn Git.

I think a "ggit" wrapper should not introduce any new commands or new parameters. Everything should be passed unmodified to Git. The wrapper would only add additional warnings such as "You are about to do X which will permanently destroy Y. Do you want to continue?". Therefore a transition from "ggit" to "git" would not require any learning effort.

Maybe "ggit" could also be interpreted as "guided Git" (sounds more friendly than "guarded Git"). I have the impression that many Git beginners make mistakes because they don't have a mental model of Git, yet. A "guided" Git version could explain the commands a bit more detailed as they use Git (e.g. with ASCII graph examples). I know that's what man pages are for but I've encountered many users (especially on Windows) that are not aware of man pages.

Show 13 quoted lines

> This approach, if it wants to become successful in helping users,
> would take quite a lot of thinking and work to avoid omitting too
> much to necessitate users to migrate to Git.  But I can very well
> imagine that a new "Cogito 2" project (I am not saying that the UI
> Cogito tried to achieve were superiour or anything of that sort--I
> just needed a name, and picked one name that came to my mind) may
> get done by those who interact rarely with the core Git community
> and may live as one of many independent and viable third-party
> projects you find on GitHub.
> 
> There however are two questions I do not offhand have good answers
> to: (1) if that kind of effort is of suitable size for GSoC, and (2)
> if it is suitable to be supported by the Git project proper.

Good questions. I have no previous experience with GSoC Git projects and therefore I am not qualified for an answer. However, my gut feeling would be that a proof of concept implementation of a "ggit" wrapper that does not add any new commands and only adds warnings for destructive commands could be in the GSoC scope. However, Sidhant must be aware of the fact that this is a controversial topic and therefore any future work on this topic might be never merged into Git.

I also thought about (2). The obvious advantage of having something like "ggit" as part of Git core is that it would be shipped with the standard Git distribution. That would especially help beginners. However, maintenance is a very strong counter argument. Maybe "ggit" could start as a separate project and if it picks up then Git core can still decide to merge it?