git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
Nov 5, 2016, 04:41 UTC
Message-ID
<xmqq60o2edy5.fsf@gitster.mtv.corp.google.com>
In-Reply-To
<20161104194907.3yxu2rkayfyic4dr@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
Show 17 quoted lines
> 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.

Previous: Jeff KingNext: Jeff King
Message 11 of 35 in “Regarding "git log" on "git series" metadata”
  1. Junio C HamanoNov 4, 2016
  2. Jacob KellerNov 4, 2016
  3. Jeff KingNov 4, 2016
  4. Josh TriplettNov 4, 2016
  5. Jacob KellerNov 4, 2016
  6. Josh TriplettNov 4, 2016
  7. Jacob KellerNov 4, 2016
  8. Jeff KingNov 5, 2016
  9. Josh TriplettNov 5, 2016
  10. Jeff KingNov 5, 2016
  11. Junio C HamanoNov 5, 2016
  12. Jeff KingNov 5, 2016
  13. Junio C HamanoNov 5, 2016
  14. Christian CouderNov 4, 2016
  15. Josh TriplettNov 4, 2016
  16. Christian CouderNov 4, 2016
  17. Stefano ZacchiroliNov 13, 2016
  18. Christian CouderNov 5, 2016
  19. Junio C HamanoNov 5, 2016
  20. Christian CouderNov 5, 2016
  21. Christian CouderNov 5, 2016
  22. Josh TriplettNov 5, 2016
  23. Christian CouderNov 5, 2016
  24. Josh TriplettNov 5, 2016
  25. Jacob KellerNov 6, 2016
  26. Josh TriplettNov 6, 2016
  27. Junio C HamanoNov 6, 2016
  28. Josh TriplettNov 6, 2016
  29. Jacob KellerNov 6, 2016
  30. Josh TriplettNov 7, 2016
  31. Jacob KellerNov 7, 2016
  32. Duy NguyenNov 7, 2016
  33. Josh TriplettNov 7, 2016
  34. Junio C HamanoNov 9, 2016
  35. Josh TriplettNov 4, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.