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

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

From
Josh Triplett <josh@joshtriplett.org>
Date
Nov 4, 2016, 23:46 UTC
Message-ID
<20161104234647.xjaf7scdjpppfdop@x>
In-Reply-To
<CA+P7+xoKORo6hC2n-E-gHG2OYg3h-m3ZnUQbdopS7S3-5AWoPQ@mail.gmail.com>
On Fri, Nov 04, 2016 at 04:37:34PM -0700, Jacob Keller wrote:
Show 18 quoted lines
> On Fri, Nov 4, 2016 at 2:55 PM, Josh Triplett <josh@joshtriplett.org> wrote:
> > That said, I'd *love* to have gitrefs available, for a wide variety of
> > applications, and I can see an argument for introducing them and waiting
> > a few years for them to become universally available, similar to the
> > process gitlinks went through.
> >
> > But I'd also love to have a backward-compatible solution.
> >
> > - Josh Triplett
> 
> I think that you won't really find a backwards compatible solution
> other than something like automatically generating refs for each point
> of history. I know that gerrit does something like this by storing
> each version in "refs/changes/id/version" or something along those
> lines. I think this might actually be cleaner than your parent links
> hack, and could be used as a fallback for when gitrefs don't work,
> though you'd have to code exactly how to tell what to push to a
> repository when pushing a series?

I'm not sure what the advantage of that would be, and it would mean that if you ever have one branch without pushing the other(s), you'd get severe time-delated breakage due to pruning. (And if you pushed the series without the other ref(s), its history would look right but then you couldn't access the underlying versions of the patch series.)

One of my design goals was to *not* need a special "git series push" or "git series pull"; you should just be able to use git push and git pull, and you can set up normal refspecs.

That said, I could fairly easily generate the existing format with artificial parent refs for backward compatibility, and provide a way to use the new gitref-based storage format if you know that all your servers and clients can handle it. I'm also open to other suggestions for how to make such a transition while still working with every git server and git client that exists today.

Previous: Jacob KellerNext: Jacob Keller
Message 6 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.