git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Jacob Keller <jacob.keller@gmail.com>,
	Josh Triplett <josh@joshtriplett.org>,
	Git mailing list <git@vger.kernel.org>
Subject: Re: Regarding "git log" on "git series" metadata
Date: Fri, 04 Nov 2016 21:41:06 -0700	[thread overview]
Message-ID: <xmqq60o2edy5.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20161104194907.3yxu2rkayfyic4dr@sigill.intra.peff.net> (Jeff King's message of "Fri, 4 Nov 2016 15:49:07 -0400")

Jeff King <peff@peff.net> writes:

> On Fri, Nov 04, 2016 at 12:19:55PM -0700, Jacob Keller wrote:
>
>> 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.

  parent reply	other threads:[~2016-11-05  4:41 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 [this message]
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
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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=xmqq60o2edy5.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=jacob.keller@gmail.com \
    --cc=josh@joshtriplett.org \
    --cc=peff@peff.net \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).