git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Clemens Buchacher <drizzd@aon.at>
To: Miles Bader <miles@gnu.org>
Cc: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>,
	git@vger.kernel.org, Peter Rabbitson <ribasushi@cpan.org>
Subject: Re: DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz"
Date: Mon, 7 Jun 2010 20:54:39 +0200	[thread overview]
Message-ID: <20100607185439.GB17343@localhost> (raw)
In-Reply-To: <buobpbnz6mh.fsf@dhlpc061.dev.necel.com>

On Mon, Jun 07, 2010 at 03:41:58PM +0900, Miles Bader wrote:
> Clemens Buchacher <drizzd@aon.at> writes:
> > The suggestion above would be perfect. It is an easy and obvious
> > solution, and the user is even educated about their mistake.
> 
> Of course, having been educated as to what's going on, the user would
> then be annoyed that they had to type all those boilerplate args when
> git clearly knew what they wanted to do... and that would be the case
> every time from then on...

Why should the user make the same mistake over and over again?

> I think this DWIM is actually pretty convenient, and very often does
> reflect what the user intuitively is trying to do when giving such args.
> 
> Given that git _does_ tell you what it's doing, and that it's easy
> enough to delete the new branch if it wasn't really wanted, it seems
> pretty harmless as well.  A campaign to delete this feature seems kind
> of silly...

It may be harmless to users who know what's going on. I can
certainly deal with this feature, whether it's there or not.

But this is supposedly a feature which helps users who type "git
checkout <branch>" by mistake, when they really wanted to do "git
checkout -t <remote>/<branch>". I am certain that most new users
who make this mistake will not understand what's going on, even if
they read the output.

I believe that it's because of things like this that many users
still consider git to be complicated and hard to use. That's what
really bothers me.

And it makes me sad that you think it silly to even talk about it.
Even if the feature does not end up getting removed I still hope
that we will exercise more caution in the future and try to solve
the real problem--which appears to be remote branch
handling--rather than introducing more strange behavior.

Regards,
Clemens

  reply	other threads:[~2010-06-07 18:55 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-05 11:09 DWIM "git checkout frotz" to "git checkout -b frotz origin/frotz" Clemens Buchacher
2010-06-05 13:29 ` Sverre Rabbelier
2010-06-05 13:58   ` Clemens Buchacher
2010-06-05 14:03     ` Sverre Rabbelier
2010-06-05 15:02       ` Clemens Buchacher
2010-06-05 18:23         ` Nicolas Pitre
2010-06-06 16:18       ` Jeff King
2010-06-06 16:55         ` Clemens Buchacher
2010-06-06 16:59           ` Jacob Helwig
2010-06-06 17:32             ` Clemens Buchacher
2010-06-06 17:34               ` Sverre Rabbelier
2010-06-06 21:26               ` Jacob Helwig
2010-06-07 18:29                 ` Clemens Buchacher
2010-06-07 20:11                   ` Jan Krüger
2010-06-07 21:12                     ` Clemens Buchacher
2010-06-06 18:34           ` Johan Herland
2010-06-06 16:18 ` Matthieu Moy
2010-06-06 16:46   ` Clemens Buchacher
2010-06-07  6:41     ` Miles Bader
2010-06-07 18:54       ` Clemens Buchacher [this message]
2010-06-07 19:17         ` Matthieu Moy
2010-06-07 19:32           ` Clemens Buchacher
2010-06-07 19:52             ` Bruce Stephens
2010-06-08  8:07             ` Michael J Gruber
2010-06-08  8:18               ` demerphq
2010-06-08  8:37                 ` Michael J Gruber
2010-06-08  0:25         ` Miles Bader
2010-06-08  7:29           ` Clemens Buchacher
2010-06-08  7:47             ` demerphq
2010-06-08 13:04               ` Matthieu Moy
2010-06-08  7:52             ` Miles Bader
2010-06-08  7:52             ` Jeff King
2010-06-08 18:13               ` Clemens Buchacher
2010-06-07  7:53     ` Paolo Bonzini

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100607185439.GB17343@localhost \
    --to=drizzd@aon.at \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=git@vger.kernel.org \
    --cc=miles@gnu.org \
    --cc=ribasushi@cpan.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).