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

Re: [RFC/GSoC] Introduction

From
Junio C Hamano <gitster@pobox.com>
Date
Mar 14, 2016, 06:57 UTC
Message-ID
<xmqqk2l58s2a.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<1924FEBB-46F2-46EE-B190-5289588D4BED@gmail.com>
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. 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.

Previous: Sidhant SharmaNext: Lars Schneider
Message 12 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.