From: Christian Couder <christian.couder@gmail.com>
To: Josh Triplett <josh@joshtriplett.org>
Cc: 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: Sat, 5 Nov 2016 21:21:58 +0100	[thread overview]
Message-ID: <CAP8UFD3XFHr7POKmZr_6guapC6sme3GvWBV5vPw4XO7FE5HOPw@mail.gmail.com> (raw)
In-Reply-To: <20161105151836.wztypzrdywyltvrc@x>
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.
> So I don't think "gitlink defined as reachable" quite works, unless we
> make some other format-incompatible change that forces clients and
> servers touching that gitlink to know about that reachability rule.  (In
> the absence of a hack such as making the same commit a parent.)
There are other tools that would like to tweak reachability rules for objects.
For example Mike Hommey's git-cinnabar:
  https://public-inbox.org/git/20150331100756.GA13377@glandium.org/
and my current work on external object databases:
  https://public-inbox.org/git/20160628181933.24620-1-chriscool@tuxfamily.org/
would be interested in a way to make some blobs not reachable.
So if we had default rules and a generic way to specify that some
objects are, or are not, reachable, that could be used by many tools,
and the design of these tools would be simplified.
Maybe this could be specified in the attributes files, or in a special
file like for shallow clone.
next prev parent reply	other threads:[~2016-11-05 20:22 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 [this message]
2016-11-05 20:25             ` Josh Triplett
2016-11-06  4:50               ` Jacob Keller
2016-11-06 16:34                 ` Josh Triplett
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=CAP8UFD3XFHr7POKmZr_6guapC6sme3GvWBV5vPw4XO7FE5HOPw@mail.gmail.com \
    --to=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=josh@joshtriplett.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).