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.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI, 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 4B2631F9FD for ; Fri, 26 Feb 2021 06:05:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229707AbhBZGAm (ORCPT ); Fri, 26 Feb 2021 01:00:42 -0500 Received: from cloud.peff.net ([104.130.231.41]:45502 "EHLO cloud.peff.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229621AbhBZGAl (ORCPT ); Fri, 26 Feb 2021 01:00:41 -0500 Received: (qmail 11832 invoked by uid 109); 26 Feb 2021 05:59:57 -0000 Received: from Unknown (HELO peff.net) (10.0.1.2) by cloud.peff.net (qpsmtpd/0.94) with ESMTP; Fri, 26 Feb 2021 05:59:57 +0000 Authentication-Results: cloud.peff.net; auth=none Received: (qmail 16179 invoked by uid 111); 26 Feb 2021 05:59:56 -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; Fri, 26 Feb 2021 00:59:56 -0500 Authentication-Results: peff.net; auth=none Date: Fri, 26 Feb 2021 00:59:56 -0500 From: Jeff King To: Patrick Steinhardt Cc: Yaron Wittenstein , git@vger.kernel.org Subject: Re: [QUESTION] Tracking HEAD changes? Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Thu, Feb 25, 2021 at 06:36:54AM +0100, Patrick Steinhardt wrote: > > Hmm, I would have thought that the branch switch would trigger the hooks > > because they're updating HEAD. I wonder if that is a bug (or lack of > > feature :) ) in the transaction hooks, or something Patrick did > > intentionally. > > It was done semi-intentionally, or at least with the knowledge that > symrefs aren't covered. This is mostly because they're not covered by > the reference transaction mechanism itself. Ah, right, I forgot about that. That might be something that we'd want to fix if anybody wanted to use the transaction hooks to track the complete state of refs. At GitHub, our repository replication does track symbolic ref updates, but we handle it outside of Git. Our normal ref updates use a few custom bits of code similar to your transaction hooks in order to implement a 3-phase commit. But our symref updates don't; they just take a lock, run git-symbolic-ref on each, and then vote on the result. This is slower and less robust, but symbolic ref updates are relatively rare, so it hasn't been a big deal. -Peff