On Monday 14 March 2016 01:46 PM, Lars Schneider wrote: > On 14 Mar 2016, at 07:57, Junio C Hamano <gitster@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html