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

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

From
Jacob Keller <jacob.keller@gmail.com>
Date
Nov 6, 2016, 04:50 UTC
Message-ID
<CA+P7+xoG3ag8dj7s_NRoqz-EwjVENSJSzE_qj6gnW-SmWt0bgA@mail.gmail.com>
In-Reply-To
<20161105202553.migx75gfuujakqyk@x>
On Sat, Nov 5, 2016 at 1:25 PM, Josh Triplett <josh@joshtriplett.org> wrote:
Show 26 quoted lines
> On Sat, Nov 05, 2016 at 09:21:58PM +0100, Christian Couder wrote:
>> 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.
>
> 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

Previous: Josh TriplettNext: Josh Triplett
Message 25 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.