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-ASN: AS53758 23.128.96.0/24 X-Spam-Status: No, score=-3.6 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_NONE, 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 6D0A11F8C6 for ; Wed, 7 Jul 2021 22:08:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230388AbhGGWKn (ORCPT ); Wed, 7 Jul 2021 18:10:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58638 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229717AbhGGWKm (ORCPT ); Wed, 7 Jul 2021 18:10:42 -0400 Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 88CFAC061574 for ; Wed, 7 Jul 2021 15:08:01 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id p1so8255352lfr.12 for ; Wed, 07 Jul 2021 15:08:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=T/gZj7+JSjjwOrHXNlKi+sjnuq3G2nRbR87zV5WYVOs=; b=t79Wi1ORnNcexD4yUj7n0fEhGgWwh1tZksOaJH/qHs1+6xxSO3KhG9SRHBj4yoxJUr itsgTAuopXfQCMTGn4TUJHr6QEkqRvbp2Q6GPBET2mQqPze7L9ZQo6NLWcZqINxxZaN7 sQVcOcrZtsx6Q1upXtci81dj09GDZI7Td7CiBOUmBZG84ReMxrMdzFQTfhnXYV3KQy78 x4W7r1KXa54qQWgecE8K7tnsRhnrVtLeTnPgyOEaBfD7ZF5RkjRJ+R+dkbmgQr4xkJww T6eQgosmNPSj3yWetIfxcF46eVluGLBaRHEyL/jak4gqSI6z6e4wswfkg+LELvMDKXeu /rDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=T/gZj7+JSjjwOrHXNlKi+sjnuq3G2nRbR87zV5WYVOs=; b=WJBsrqW1wxbpCjFHgbkuPmljkq07pgWGynajMDAJDtr9k7tmqxCqHi8pvtkETUtH3G qnlPcifRtmffeIcnAHgbg+bRrFSNk6bpizKDQMcGlOtZvf/92HHTrv1gnZrymQB04XJY wVDxq0uENk/vjkQFh9CMK8RxuqxqnhMxjFSHyTQrL18lSp8OjyLjxskOhpqFl17g17WE hBWxVMIDzjGzFkbDANCvEpDPWnN+1EBelsgSQ0CBTf2pkn7U1ZeaVIfpcPyJM4/uRXH+ sGz5MwjUvAKsHCznshbvjUZwGAyWwo9y9tXdPeLfQ4koPjIOQLCRtbtDvXIQv+nEdwF8 7+Jg== X-Gm-Message-State: AOAM530kRcjS0tvdGXba7m+yMSoH5Kc3UFwXFWRIArEBiLEMERF0+O5V 2ebgOUmNpUDZAVfNTBM8DSs6eqmNQYg= X-Google-Smtp-Source: ABdhPJxjI9YUIRqX5FhZqcFa50peKDewekUa9DaMBpVW/PwtT3s5fZb3w4jfsRPfYnuyTpTXRZ0pCg== X-Received: by 2002:ac2:4d51:: with SMTP id 17mr16317537lfp.618.1625695679434; Wed, 07 Jul 2021 15:07:59 -0700 (PDT) Received: from osv.localdomain ([89.175.180.246]) by smtp.gmail.com with ESMTPSA id m6sm13164lfu.238.2021.07.07.15.07.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Jul 2021 15:07:58 -0700 (PDT) From: Sergey Organov To: Felipe Contreras Cc: Martin , Junio C Hamano , git@vger.kernel.org Subject: Re: What actually is a branch? References: <7870a0ad-8fa1-9dbd-1978-1f44ec6970c5@mfriebe.de> <87wnqaclz8.fsf@osv.gnss.ru> <60e5f3981de5f_301437208bc@natae.notmuch> <87bl7d3l8r.fsf@osv.gnss.ru> <60e61bbd7a37d_3030aa2081a@natae.notmuch> Date: Thu, 08 Jul 2021 01:07:57 +0300 In-Reply-To: <60e61bbd7a37d_3030aa2081a@natae.notmuch> (Felipe Contreras's message of "Wed, 07 Jul 2021 16:25:17 -0500") Message-ID: <877di13hhe.fsf@osv.gnss.ru> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Felipe Contreras writes: > Since this is not strictly related to the topic of `git switch` I > renamed the thread. > > Sergey Organov wrote: >> Felipe Contreras writes: >> > Sergey Organov wrote: > >> >> Overall, if we aim at clear documentation, we need to define our >> >> documentation terms as precise as possible, and then use them >> >> consistently. >> >> >> >> For example: >> >> >> >> "branch": a chain of commits >> >> >> >> "branch tip": the most recent commit in a branch >> >> >> >> "branch name": specific type of symbolic reference pointing to a >> >> branch tip >> > >> > Completely agree on all three (although I would call it "branch head", >> > not "branch tip"). >> >> I see why "branch head", as you later introduce "branch tail", but a >> branch (of a plant) has no "head" (nor "tail"), right? BTW, how the base >> of a plant branch is called in English, and how one finds "branch tail" >> on a real tree anyway? I mean, there are probably a few of them, at >> every fork. In Git it's even more vague, as a branch could logically >> begin at any place, not necessarily at a fork point. > > We don't necessarily need a 1-to-1 mapping with common English (although > that would be nice). Anoher option could be "base" and "tip". > >> OTOH, "head" and "tail" are obviously taken from CS "list" concept, and, >> provided "chain" == "list", it does make sense. > > I took it from Mercurial, where the tip of a branch is called "head", > and in fact a branch can have multiple heads. > >> And then we have 'HEAD' that points to the current branch tip anyway. > > It actually points to a branch, or rather references a branch, since it > uses the branch name. Yes, but it still points to the branch tip, indirectly, or even directly, when in "detached head" state, that, by the way, I'd vote to abandon, replacing it with more user-friendly "unnamed branch" or something like that. > >> Dunno, in fact I don't have any preference among "tip" and "head". > > I don't either, but from different sources (non-git-specific) I've heard > "head" more often. > >> As for branch tail, I do have convention of marking start of a >> long-standing branch with corresponding tag, where branch "foo" has >> corresponding "foo-bp" tag marking its "branch point". Recently I >> started to mark start of feature branch with yet another branch "foo-bp" >> rather than tag, "foo" being set to track "foo-bp", that allows to >> automate rebasing of "foo" against correct base. > > So foo-bp is the upstream of foo, and you do basically: > > git rebase foo@{upstream} Yep, but essential feature to me is that I in fact use tools that simply run bare git rebase and that "just works" (tm). > > This is works if your base (or tail, or whatever) is static, but many > branches jump around, and that's where @{tail} comes in handy. Yeah, I see. When I need to make a branch jump around, I do need to manually move my references, but that's fortunately very rare use-case for me. Having direct support for that is still a win. > > You can do this: > > git rebase --onto foo@{upstream} foo@{tail} > > This will always rebase the right commits (no need to look into the > reflog). So you can say that the branch is foo@{tail}..foo. I see where and when it's useful, but for a feature branch 99% of times I don't want to rebase it onto some true upstream. I rather want to just fiddle with the branch in place, and I prefer to setup things the way that ensures that bare "git rebase" does "the right thing". Probably that could be solved by a branch-local configuration that makes "git rebase" become "git rebase @{tail}" for the branch instead of "git rebase @{upstream}" > > Another advantage of having this notion is that `git rebase` > automatically updates the tail (in this case to foo@{upstream}). Yep, looks useful. Is it all local to given repo, or else? Thanks, -- Sergey Organov