Re: [PATCH] gitk: disable checkout of remote branch
On Sun, Jun 21, 2009 at 2:52 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 16 quoted lines
>
> Sitaram Chamarty <sitaramc@gmail.com> writes:
>
> > At the command line, this gives you a detailed warning message, but the
> > GUI currently allows it without any fuss.
> >
> > Since the GUI is often used by people much less familiar with git, it
> > seems reasonable to make the GUI more restrictive than the command line,
> > not less.
> > ...
> > This patch helps me a lot.
>
> The patch seems to disable checkout unconditionally, but it at least needs
> an "expert mode" switch to bypass the patch's logic, or (better yet) a
> "training wheel" switch for you to set in repositories of the people you
> manage.
Indeed it does disable checkout of a remote/* branch unconditionally.
I'm not just thinking of people *I* teach when I say that the "training wheel" mode should be the default.
I believe that when someone does this _from the GUI_, it's 100% certain they intended something else. My basis for saying so is (1) even from CLI, it is quite likely, which is why we have a warning, and (2) people who use GUI are often much less expert than people who use CLI.
Actually, what are the odds that someone is expert enough to use a detached HEAD _properly_ (without shooting themselves in the foot), but is _not_ expert enough to just say "git checkout origin/master" at the CLI? I did not think that combination is worth bothering about.
You're welcome to tell me I'm wrong and that there _are_ such people -- you guys are the gurus here -- but this is what I believe :-)
[Of course, I could just be trying to cover up the fact that those were literally the first 3 lines of Tcl I ever wrote in all my life, and the size and scope of gitk is well beyond my comprehension to do anything non-trivial :-) I'll let you decide which it is, heh!]
Show 9 quoted lines
>
> The above should ideally read:
>
> > diff --git a/gitk b/gitk
> > index 8c66d17..411bc52
> > --- a/gitk
> > +++ b/gitk
>
> if the patch goes to Paulus.
Thanks -- I had not realised that subtlety.
Will make that change and re-send after hearing from either of you about the above. Because if the decision is that the patch does need to be conditional etc., it'll take me a long while anyway :-(
Regards,
Sitaram