git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFC/GSoC] Introduction

From
Sidhant Sharma <tigerkid001@gmail.com>
Date
Mar 14, 2016, 15:56 UTC
Message-ID
<56E6DF17.2040106@gmail.com>
In-Reply-To
<FB2E0900-A77E-4AE2-A580-9192746A8ABA@gmail.com>
On Monday 14 March 2016 01:46 PM, Lars Schneider wrote:
Show 18 quoted lines
> 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).

Show 29 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?
>

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

Previous: Lars SchneiderNext: Matthieu Moy
Message 14 of 23 in “[RFC/GSoC] Introduction”
  1. Sidhant SharmaMar 12, 2016
  2. Lars SchneiderMar 13, 2016
  3. Sidhant SharmaMar 13, 2016
  4. Kevin DaudtMar 13, 2016
  5. Sidhant SharmaMar 14, 2016
  6. Jacob KellerMar 14, 2016
  7. Junio C HamanoMar 14, 2016
  8. Jacob KellerMar 13, 2016
  9. Sidhant SharmaMar 14, 2016
  10. Jacob KellerMar 14, 2016
  11. Sidhant SharmaMar 14, 2016
  12. Junio C HamanoMar 14, 2016
  13. Lars SchneiderMar 14, 2016
  14. Sidhant SharmaMar 14, 2016
  15. Matthieu MoyMar 20, 2016
  16. Junio C HamanoMar 14, 2016
  17. Matthieu MoyMar 20, 2016
  18. Philip OakleyMar 14, 2016
  19. Sidhant SharmaMar 17, 2016
  20. Lars SchneiderMar 20, 2016
  21. Sidhant SharmaMar 20, 2016
  22. Lars SchneiderMar 20, 2016
  23. Sidhant SharmaMar 20, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.