Re: Regarding "git log" on "git series" metadata

Christian Couder [off-list ref] writes:

Couldn't a RefTree be used to store refs that point to the base
commit,

I think it is the other way around.  With the new "gitref" thing
that is a pointer to an in-repository commit, RefTree can be
naturally implemented.

On Sat, Nov 5, 2016 at 5:42 AM, Junio C Hamano [off-list ref] wrote:

Christian Couder [off-list ref] writes:

quoted

Couldn't a RefTree be used to store refs that point to the base
commit,

I think it is the other way around.  With the new "gitref" thing
that is a pointer to an in-repository commit, RefTree can be
naturally implemented.

Yeah, I should have read Shawn's RefTree email thread again before
posting and especially before replying to Josh.

On Sat, Nov 5, 2016 at 1:17 PM, Christian Couder
[off-list ref] wrote:

On Sat, Nov 5, 2016 at 5:42 AM, Junio C Hamano [off-list ref] wrote:

quoted

Christian Couder [off-list ref] writes:

quoted

Couldn't a RefTree be used to store refs that point to the base
commit,

I think it is the other way around.  With the new "gitref" thing
that is a pointer to an in-repository commit, RefTree can be
naturally implemented.

Yeah, I should have read Shawn's RefTree email thread again before
posting and especially before replying to Josh.

By the way, reading the following email by Peff where gitlink
reachability was already discussed:

https://public-inbox.org/git/20151217221045.GA8150@sigill.intra.peff.net/

and where Peff wrote:

Of course, the lack of reachability has advantages, too. You can
drop commits pointed to by old reflogs without rewriting the ref
history. Unfortunately you cannot expunge the reflogs at all. That's
good if you like audit trails. Bad if you are worried that your reflogs
will grow large. :)

I think that we may not need "gitref" at all. We perhaps could just
have more ways to configure and tweak how a repo manages commit
reachability related to gitlinks.

With shallow clones we already need ways to configure and tweak commit
reachability anyway.

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?

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.

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.)

On Sat, Nov 5, 2016 at 4:18 PM, Josh Triplett [off-list ref] wrote:

On Sat, Nov 05, 2016 at 01:45:27PM +0100, Christian Couder wrote:

quoted

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.

On Sat, Nov 05, 2016 at 09:21:58PM +0100, Christian Couder wrote:

On Sat, Nov 5, 2016 at 4:18 PM, Josh Triplett [off-list ref] wrote:

quoted

On Sat, Nov 05, 2016 at 01:45:27PM +0100, Christian Couder wrote:

quoted

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

On Sat, Nov 5, 2016 at 1:25 PM, Josh Triplett [off-list ref] wrote:

On Sat, Nov 05, 2016 at 09:21:58PM +0100, Christian Couder wrote:

quoted

On Sat, Nov 5, 2016 at 4:18 PM, Josh Triplett [off-list ref] wrote:

quoted

On Sat, Nov 05, 2016 at 01:45:27PM +0100, Christian Couder wrote:

quoted

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?

Thanks.
Jake

On Sat, Nov 05, 2016 at 09:50:07PM -0700, Jacob Keller wrote:

On Sat, Nov 5, 2016 at 1:25 PM, Josh Triplett [off-list ref] wrote:

quoted

On Sat, Nov 05, 2016 at 09:21:58PM +0100, Christian Couder wrote:

quoted

On Sat, Nov 5, 2016 at 4:18 PM, Josh Triplett [off-list ref] wrote:

quoted

On Sat, Nov 05, 2016 at 01:45:27PM +0100, Christian Couder wrote:

quoted

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.