Re: [RFC/GSoC] Introduction

[Sidhant Sharma <tigerkid001@gmail.com>]

On Monday 14 March 2016 01:46 PM, Lars Schneider wrote:
> On 14 Mar 2016, at 07:57, Junio C Hamano <gitster@pobox.com> wrote:
>
>> 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.
I too think that the wrapper should only pass on commands to git if
they aren't potentially destructive, and not itself introduce
new commands, unless there is a need (I doubt if there will be).
>
>> 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?
>
I understand that this endeavour may or may not be merged into
the official Git distribution (though I'd really like it to :)), but
I still wish to attempt this. I'm also eager to continue work on this
even after GSoC is over, so maintenance shouldn't be an issue ;)

Thanks and regards,
Sidhant Sharma