From: "Philip Oakley" <philipoakley@xxxxxxx> Sent: March 14, 2016 9:08 PM
From: "Lars Schneider" <larsxschneider@xxxxxxxxx>
On 14 Mar 2016, at 07:57, Junio C Hamano <gitster@xxxxxxxxx> wrote:
Lars Schneider <larsxschneider@xxxxxxxxx> 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.
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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