From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.176.0/21 X-Spam-Status: No, score=-3.5 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MSGID_FROM_MTA_HEADER,RP_MATCHES_RCVD shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 From: Carl Worth Subject: Re: Cleaning up git user-interface warts Date: Wed, 15 Nov 2006 13:08:58 -0800 Message-ID: <87velgs9hx.wl%cworth@cworth.org> References: <87k61yt1x2.wl%cworth@cworth.org> <200611151858.51833.andyparkins@gmail.com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/signed; boundary="pgp-sign-Multipart_Wed_Nov_15_13:08:58_2006-1"; micalg=pgp-sha1; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit NNTP-Posting-Date: Wed, 15 Nov 2006 21:09:39 +0000 (UTC) Cc: Nicolas Pitre , "Michael K. Edwards" , git@vger.kernel.org Return-path: Envelope-to: gcvg-git@gmane.org In-Reply-To: User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.4 Mule/5.0 (SAKAKI) Precedence: bulk X-Mailing-List: git@vger.kernel.org Archived-At: Received: from vger.kernel.org ([209.132.176.167]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GkS0i-0000G0-S4 for gcvg-git@gmane.org; Wed, 15 Nov 2006 22:09:33 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161506AbWKOVJ2 (ORCPT ); Wed, 15 Nov 2006 16:09:28 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1161523AbWKOVJ2 (ORCPT ); Wed, 15 Nov 2006 16:09:28 -0500 Received: from theworths.org ([217.160.253.102]:29083 "EHLO theworths.org") by vger.kernel.org with ESMTP id S1161506AbWKOVJ1 (ORCPT ); Wed, 15 Nov 2006 16:09:27 -0500 Received: (qmail 10582 invoked from network); 15 Nov 2006 16:09:15 -0500 Received: from localhost (HELO raht.cworth.org) (127.0.0.1) by localhost with SMTP; 15 Nov 2006 16:09:15 -0500 To: Linus Torvalds Sender: git-owner@vger.kernel.org --pgp-sign-Multipart_Wed_Nov_15_13:08:58_2006-1 Content-Type: text/plain; charset=US-ASCII On Wed, 15 Nov 2006 12:40:43 -0800 (PST), Linus Torvalds wrote: > On Wed, 15 Nov 2006, Nicolas Pitre wrote: > > > > Actually I believe it would make things even clearer if "merge" was > > taught at that point. Only when the user is comfortable with the > > separate notions of fetching and merging might the pull shorthand > > possibly be mentioned. > > I agree. I just expect that "merge" is such a simple concept that it > doesn't really need a whole lot of explaining. Well, one of the problems is that with current git I can teach, (and I have), that there's a conceptual: pull = fetch + merge But then shortly after I have to teach an interface notion: merge = pull . So there's this goofy circular notion that people end up with mentally. If we fix it so that a local merge really is performed with "git merge " instead of "git pull . " then teaching pull=fetch+merge really is a lot easier. In the meantime, pull would still be useless to me, I think. But maybe that's just the "default branch to merge" selection being broken. If that were fixed, maybe I would start using pull. > (a) explain what "branches" mean in git (and in that situation, "fetch" > is very natural - I think fetching itself is probably easier to > explain than "branches" are). There's a piece missing here, namely the mapping between remote and local branch names and any notion of "tracking branches". I think a sane story for that is still being invented, (or if it exists now, I haven't seen it yet). > (c) once "fetching branches" and "merging" have been explained, "pull" is > really pretty damn trivial, and in fact, if you then explain that > it's just easier to do "git pull . branchname" than to use "git > merge", I think people may just even agree with you. Well, they get pretty darn confused at this point, in my experience. > Once you understand local branches, fetching and merging, it's actually > _easier_ to explain why we merge even local branches with "git pull .": > you just tell them that this way you can use the same command regardless > of whether you're merging something local or something remote. Again, if > it's explained that way, I bet a lot of people react with "ahh, that's > clever", and _like_ the fact that they only really need to learn _one_ > command, instead of learning two. No. It's really, really broken to use "pull ." for local merging. Not a feature at all. We just got done establishing that pull is a shorthand for doing fetch+merge, so reusing it when there is _no_ fetch at all is insane. You just established quite clearly hat git has a huge advantge over all other systems by having a model that everything is fetched in and then worked with locally. I agree that this is a major selling-point of git, and I'm also baffled that systems like bzr and hg try so hard to push every branch into a separate repository. But I think that git's "work with everything locally" story is undercut a bit by regular usage being to use a transfer-inducing command like "pull" for a totally local merge. Anyway, I think we all agree that we'd really rather have "git merge " be usable for local merges, so let's get that in place and users can pick whichever they like. > But the real issue here is to explain local branches. I will happily admit > that local branches are very VERY different from just about any other SCM, > but I also claim that git is just much BETTER than other SCM's in this > respect. Totally agree. -Carl --pgp-sign-Multipart_Wed_Nov_15_13:08:58_2006-1 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBFW4Hq6JDdNq8qSWgRAr3OAJkBDKpe8W61HdQmpCep+6ZeWjqdZgCfa1qV tyjjFBxE92fDZALmf4kz83c= =UOh4 -----END PGP SIGNATURE-----