Re: [RFC/GSoC] Introduction

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 14, 2016, 17:25 UTC
Message-ID: <xmqq7fh5as54.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <FB2E0900-A77E-4AE2-A580-9192746A8ABA@gmail.com>

Lars Schneider <larsxschneider@gmail.com> writes:

Show 11 quoted lines

> On 14 Mar 2016, at 07:57, Junio C Hamano <gitster@pobox.com> wrote:
>
>> 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....
>> ...
>
> 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...

Somehow I was assuming that you are aiming for a more ambitious project, where the users get an easier-to-learn-and-understand command line UI experience than bare Git [*1*], but none of what I said about "limiting and omitting" applies if "ggit" will be a "passthru after examining what goes on" wrapper.

Show 7 quoted lines

> 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.

ounds like a lot of work but still a sensible goal. And that leaves no room for questioning if it is suitable for Git GSOC, at least to me--it does fall into the scope of making experience of learning better for Git itself.

Thanks.

[Footnote]

*1* For example, subversion migrants may say it is confusing to call
    the command "checkout" that is used to clobber files in the
    working tree to the state in the index and may want to call it
    "revert"--and "$SCM revert $path" would be the way the more
    ambitious project would let its users do that operation; it
    would call underlying "git checkout $path" for its users.
    There are other command line UI restructuring that will not
    belong to Git itself but an alternative UI front-end may want to
    use, e.g. "$SCM diff INDEX WORKTREE $pathname" that is turned
    into "git diff $pathname" and "$SCM diff HEAD INDEX $pathname"
    that is turned into "git diff --cached HEAD $pathname".