From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.8 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by dcvr.yhbt.net (Postfix) with ESMTP id E23DC2021E for ; Sun, 6 Nov 2016 16:34:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751093AbcKFQeT (ORCPT ); Sun, 6 Nov 2016 11:34:19 -0500 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:52828 "EHLO relay3-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750935AbcKFQeT (ORCPT ); Sun, 6 Nov 2016 11:34:19 -0500 Received: from mfilter48-d.gandi.net (mfilter48-d.gandi.net [217.70.178.179]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 7719EA80D0; Sun, 6 Nov 2016 17:34:17 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter48-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter48-d.gandi.net (mfilter48-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id zvVMsWmkoQYZ; Sun, 6 Nov 2016 17:34:15 +0100 (CET) X-Originating-IP: 50.39.170.172 Received: from x (50-39-170-172.bvtn.or.frontiernet.net [50.39.170.172]) (Authenticated sender: josh@joshtriplett.org) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id B8CCAA80CE; Sun, 6 Nov 2016 17:34:12 +0100 (CET) Date: Sun, 6 Nov 2016 09:34:10 -0700 From: Josh Triplett To: Jacob Keller Cc: Christian Couder , Junio C Hamano , git , "Shawn O. Pierce" , Jeff King , Nguyen Thai Ngoc Duy , Mike Hommey Subject: Re: Regarding "git log" on "git series" metadata Message-ID: <20161106163410.ilysej5r6qd3744e@x> References: <20161105151836.wztypzrdywyltvrc@x> <20161105202553.migx75gfuujakqyk@x> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20161014 (1.7.1) Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org On Sat, Nov 05, 2016 at 09:50:07PM -0700, Jacob Keller wrote: > On Sat, Nov 5, 2016 at 1:25 PM, Josh Triplett wrote: > > On Sat, Nov 05, 2016 at 09:21:58PM +0100, Christian Couder wrote: > >> On Sat, Nov 5, 2016 at 4:18 PM, Josh Triplett wrote: > >> > On Sat, Nov 05, 2016 at 01:45:27PM +0100, Christian Couder wrote: > >> >> And with what Peff says above it looks like we will need ways > >> >> configure and tweak commit reachability with gitlink/gitref anyway. So > >> >> the point of gitref compared to gitlink would be that they just have a > >> >> different reachability by default. But couldn't that be replaced by a > >> >> default rule saying that when a gitlink is reached "this way or that > >> >> way" then the commit reachability should be enforced, and otherwise it > >> >> should not be? > >> > > >> > Any version of git unaware of that rule, though, would consider objects > >> > only reachable by gitlink as unreachable and delete them, causing data > >> > loss. Likewise for a server not aware of that rule. And a server > >> > unaware of that rule would not supply those objects to a client pulling > >> > such a branch. > >> > >> Yeah, so you would really need an up-to-date server and client to > >> store the git-series data. > >> But anyway if we create a gitref object, you would also need > >> up-to-date servers and clients to make it work. > > > > Agreed, but gitrefs have the advantage of failing safe, rather than > > failing with dataloss. > > > > - Josh Triplett > > Isn't the "failing safe" only true if the client disconnects when a > server doesn't advertise "i understand gitrefs"? So couldn't we, as > part of the rules for reachability advertise a capability that does a > similar thing and fails safe as well? We could, but if we (or one of the many third-party git implementations) miss a case, gitlinks+reachability may appear to work in many cases with dataloss afterward, while gitrefs will fail early and not appear functional.