Philip OakleyFrom: "Philip Oakley" <philipoakley@iee.org> Sent: March 14, 2016 9:08 PM
Show 63 quoted lines
> From: "Lars Schneider" <larsxschneider@gmail.com> >> >> On 14 Mar 2016, at 07:57, Junio C Hamano <gitster@pobox.com> wrote: >> >>> 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. >> >> 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). > > +1 on "guided" as a softer more (beginner) friendly term. > >> 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. > > In previous discussion it has been said that that (teaching and > explaining) is not the purpose of man pages. Rather, the man pages are for > reference for those who already have a reasonable idea of what they are > doing, and use the man page to check on details. > > Whether the man pages should have more examples (or a makefile option to > include them) may be part of the beginner mode mix, and may come out of > (or go into) the guidance examples. > > The Git data model is very powerful and it does take a lot of 'unlearning' > of old expectations (which is very hard) before the capabilities of the > git model become well established in the users mind.
> For example, remote tracking branches are not remote but local, and are > a reverse polish description (a local branch which keeps track of a > remote's branch, from the last time you looked).
This just came up on the $gmane/289454 thread "When does git check for branch-X being uptodate with origin/branch-X?" (21 Mar '16).
In that case, the issue was that the 'tracking' is not active, instead it's a passive status that can become out of date, resulting in confusion about the true status. This also is a issue because of the lack of a common, in a broad world view, set of words for the problem.
Perhaps a 'have you fetched recently?' could be added for the beginner mode.
Show 43 quoted lines
> > Different people get different parts of the model in different orders and > different rates. Identifying the many issues (in model understanding) may > be a start for identifying which command/options should be targeted. > >> >> >>> 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? >> >> >> -- >> To unsubscribe from this list: send the line "unsubscribe git" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> >