From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_PASS, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by dcvr.yhbt.net (Postfix) with ESMTP id 09D111F4B4 for ; Tue, 15 Dec 2020 02:40:56 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728239AbgLOCje (ORCPT ); Mon, 14 Dec 2020 21:39:34 -0500 Received: from cloud.peff.net ([104.130.231.41]:60788 "EHLO cloud.peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728243AbgLOCjT (ORCPT ); Mon, 14 Dec 2020 21:39:19 -0500 Received: (qmail 11582 invoked by uid 109); 15 Dec 2020 02:38:34 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Tue, 15 Dec 2020 02:38:34 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 7022 invoked by uid 111); 15 Dec 2020 02:38:33 -0000 Received: from coredump.intra.peff.net (HELO sigill.intra.peff.net) (10.0.0.2) by peff.net (qpsmtpd/0.94) with (TLS_AES_256_GCM_SHA384 encrypted) ESMTPS; Mon, 14 Dec 2020 21:38:33 -0500 Authentication-Results: peff.net; auth=none Date: Mon, 14 Dec 2020 21:38:32 -0500 From: Jeff King To: =?utf-8?B?w4Z2YXIgQXJuZmrDtnLDsA==?= Bjarmason Cc: Junio C Hamano , Jonathan Tan , git@vger.kernel.org, Felipe Contreras Subject: Re: [PATCH] clone: in protocol v2, use remote's default branch Message-ID: References: <20201208013121.677494-1-jonathantanmy@google.com> <20201211210508.2337494-1-jonathantanmy@google.com> <87blewwoil.fsf@evledraar.gmail.com> <878s9zx2ul.fsf@evledraar.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <878s9zx2ul.fsf@evledraar.gmail.com> Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Tue, Dec 15, 2020 at 02:41:38AM +0100, Ævar Arnfjörð Bjarmason wrote: > > > Another reason I'm not a fan of it is because it's another piece of > > > magic "clone" does that you can't emulate in "init/fetch". > > > > That ship has sailed longlonglong time ago when dfeff66e (revamp > > git-clone., 2006-03-20) started pointing our HEAD to match theirs. > > Let me rephrase: I think it's unfortunate when we add new things things > to porcelain commands that aren't easy or possible to emulate in > plumbing. > > I.e. this feature seems like a candidate to be exposed by something like > by a ls-remote flag if you'd like to do an init/config/fetch. AFAIK the > only way to do it is to mock a "clone" with GIT_TRACE_PACKET or get the > information out-of-bounds. I think the situation is better than that. We are surfacing the remote HEAD here, and there is already a command for copying that to our local tracking symref: "git remote set-head origin -a", which will set up refs/remotes/origin/HEAD. I think there are two ways we could improve that further: - making it more natural to pick up or update the remote HEAD via fetch; Felipe's patches to git-fetch look good to me - it might be nice to be able to have some equivalent to the dwim "git checkout foo" that creates a new "foo" based off of origin/foo. Doing "git checkout origin/HEAD" will detach the HEAD. I think right now you'd have to do something like: tracking=$(git symbolic-ref refs/remotes/origin/HEAD) branch=${tracking#refs/remotes/origin/} git checkout -b $branch $tracking Or maybe not. It's not something people probably need to do a lot. And if the point is to have plumbing commands that can do the same, then maybe those commands are sufficient. -Peff