All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Triplett <josh@joshtriplett.org>
To: Jacob Keller <jacob.keller@gmail.com>
Cc: Christian Couder <christian.couder@gmail.com>,
	Junio C Hamano <gitster@pobox.com>, git <git@vger.kernel.org>,
	"Shawn O. Pierce" <spearce@spearce.org>,
	Jeff King <peff@peff.net>,
	Nguyen Thai Ngoc Duy <pclouds@gmail.com>,
	Mike Hommey <mh@glandium.org>
Subject: Re: Regarding "git log" on "git series" metadata
Date: Sun, 6 Nov 2016 09:34:10 -0700	[thread overview]
Message-ID: <20161106163410.ilysej5r6qd3744e@x> (raw)
In-Reply-To: <CA+P7+xoG3ag8dj7s_NRoqz-EwjVENSJSzE_qj6gnW-SmWt0bgA@mail.gmail.com>

On Sat, Nov 05, 2016 at 09:50:07PM -0700, Jacob Keller wrote:
> On Sat, Nov 5, 2016 at 1:25 PM, Josh Triplett <josh@joshtriplett.org> 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 <josh@joshtriplett.org> 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.

  reply	other threads:[~2016-11-06 16:34 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-04 17:57 Regarding "git log" on "git series" metadata Junio C Hamano
2016-11-04 19:19 ` Jacob Keller
2016-11-04 19:49   ` Jeff King
2016-11-04 21:55     ` Josh Triplett
2016-11-04 23:37       ` Jacob Keller
2016-11-04 23:46         ` Josh Triplett
2016-11-04 23:34     ` Jacob Keller
2016-11-05  1:48       ` Jeff King
2016-11-05  3:55         ` Josh Triplett
2016-11-05  4:41           ` Jeff King
2016-11-05  4:41     ` Junio C Hamano
2016-11-05  4:44       ` Jeff King
2016-11-05  5:00       ` Junio C Hamano
2016-11-04 20:47 ` Christian Couder
2016-11-04 21:19   ` Josh Triplett
2016-11-04 23:04     ` Christian Couder
2016-11-13 17:50       ` Stefano Zacchiroli
2016-11-05 21:56     ` Christian Couder
2016-11-05  4:42   ` Junio C Hamano
2016-11-05 12:17     ` Christian Couder
2016-11-05 12:45       ` Christian Couder
2016-11-05 15:18         ` Josh Triplett
2016-11-05 20:21           ` Christian Couder
2016-11-05 20:25             ` Josh Triplett
2016-11-06  4:50               ` Jacob Keller
2016-11-06 16:34                 ` Josh Triplett [this message]
2016-11-06 17:14                   ` Junio C Hamano
2016-11-06 17:33                     ` Josh Triplett
2016-11-06 20:17                       ` Jacob Keller
2016-11-07  1:18                         ` Josh Triplett
2016-11-07  5:35                           ` Jacob Keller
2016-11-07  9:42                           ` Duy Nguyen
2016-11-07 16:11                             ` Josh Triplett
2016-11-09 22:57                       ` Junio C Hamano
2016-11-04 21:06 ` Josh Triplett

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161106163410.ilysej5r6qd3744e@x \
    --to=josh@joshtriplett.org \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jacob.keller@gmail.com \
    --cc=mh@glandium.org \
    --cc=pclouds@gmail.com \
    --cc=peff@peff.net \
    --cc=spearce@spearce.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.