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

Jeff King [off-list ref] writes:

On Fri, Nov 04, 2016 at 12:19:55PM -0700, Jacob Keller wrote:

quoted

I agree with your assessment here. The main difficulty in implementing
gitrefs is to ensure that they actually do get picked up by
reachability checks to prevent dropping commits. I'm not sure how easy
this is, but I would much rather we go this route rather than
continuing along with the hack. This seems like the ideal solution,
since it solves the entire problem and doesn't need more hacks bolted
on.

I think the main complication is that the reachability rules are used
during object transfer. So you'd probably want to introduce some
protocol extension to say "I understand gitrefs", so that when one side
says "I have sha1 X and its reachable objects", we know whether they are
including gitrefs there. And likewise receivers with
transfer.fsckObjects may complain about the new gitref tree mode
(fortunately a new object type shouldn't be needed).

Quite honestly I do not think backward compatibility here matters.
When gitlinks were introduced, a repository that was created with
gitlink capable version of Git would have failed "git fsck" that is
not gitlink aware, and I think this new "link with reachability" is
the same deal.  No existing implemention understands a tree entry
whose mode bits are 140000 or whatever new bit pattern we would
assign to this thing.  You have to wait until both ends understand
the new thing, and that is perfectly OK.

Besides, I think the point of having this discussion is that Josh
did a good prototyping work of "git series" to discover what he can
do in that area of "keeping track of history of history" and what
operations are useful, without wasting time on mucking with the
object model and traversal machinery that are available to him.  

Now his prototyping is at the point where he knows at least one
enhancement to the core that would help him to redo the prototype in
the right way.  And I do not mind helping him from the core side.

On Fri, Nov 04, 2016 at 09:41:06PM -0700, Junio C Hamano wrote:

quoted

I think the main complication is that the reachability rules are used
during object transfer. So you'd probably want to introduce some
protocol extension to say "I understand gitrefs", so that when one side
says "I have sha1 X and its reachable objects", we know whether they are
including gitrefs there. And likewise receivers with
transfer.fsckObjects may complain about the new gitref tree mode
(fortunately a new object type shouldn't be needed).

Quite honestly I do not think backward compatibility here matters.
When gitlinks were introduced, a repository that was created with
gitlink capable version of Git would have failed "git fsck" that is
not gitlink aware, and I think this new "link with reachability" is
the same deal.  No existing implemention understands a tree entry
whose mode bits are 140000 or whatever new bit pattern we would
assign to this thing.  You have to wait until both ends understand
the new thing, and that is perfectly OK.

I'm OK with saying "if you use the gitref feature, you cannot push or
pull those objects with remotes that do not understand it".  But unlike
gitlink, if we fail to notice the situation, we run into a case where we
might silently lose objects, which is bad. So I think we need to be a
bit more careful.

I don't think the problems are insurmountable. I just think that's where
the real complexity is, not in the changes to teach a single git about
gitrefs.

I'm happy to stand back and let you or Josh figure out all the corner
cases. :)

-Peff