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

Re: [PATCH] technical doc: add a design doc for the evolve command

From
SXStefan Xenos <sxenos@google.com>
Date
Nov 21, 2018, 19:10 UTC
Message-ID
<CAPL8ZitRThJmqyvvf7-Cw=aSmPMcpqr8wvFVeJ3tfGY5feFH9g@mail.gmail.com>
In-Reply-To
<20181121013326.GF149929@google.com>
>   I don't have a strong opinion about whether this would go in the
> design doc.  I suppose the doc could have an "implementation plan"
> section describing temporary stopping points on the way to the final
> result, but it's not necessary to include that.

As long as this is something I'm just doing for fun and nobody needs to coordinate anything with me, I was planning to just document the endpoint and then work on whatever seems interesting at any given moment. Of course, if I found a job/team that would let me do this as my day job, I'd be more willing to commit to deliverables.

  - Stefan
On Tue, Nov 20, 2018 at 5:33 PM Jonathan Nieder <jrnieder@gmail.com> wrote:
Show 26 quoted lines
>
> Stefan Xenos wrote:
> > Jonathan Nieder wrote:
>
> >> putting it in the commit message is a way to
> >> experiment with the workflow without changing the object format
> >
> > As long as we're talking about a temporary state of affairs for users
> > that have opted in, and we're explicit about the fact that future
> > versions of git won't understand the change graphs that are produced
> > during that temporary state of affairs, I'm fine with using the commit
> > message. We can move it to the header prior to enabling the feature by
> > default.
>
> Yay!  I think that addresses both my and Ævar's concerns.  Also, if
> you run into an issue that requires changing the object format
> earlier, that's fine and we can handle the situation when it comes.
>
> I don't have a strong opinion about whether this would go in the
> design doc.  I suppose the doc could have an "implementation plan"
> section describing temporary stopping points on the way to the final
> result, but it's not necessary to include that.
>
> Thanks for the quick and thoughtful replies.
>
> Jonathan
Previous: Jonathan NiederNext: Derrick Stolee
Message 14 of 37 in “technical doc: add a design doc for the evolve command”
  1. technical doc: add a design doc for the evolve commandsxenos@google.com, Nov 15, 2018
  2. Johannes SchindelinNov 15, 2018
  3. Stefan XenosNov 17, 2018
  4. SZEDER GáborNov 19, 2018
  5. Stefan XenosNov 19, 2018
  6. Jonathan NiederNov 20, 2018
  7. Ævar Arnfjörð BjarmasonNov 15, 2018
  8. Jonathan NiederNov 20, 2018
  9. Ævar Arnfjörð BjarmasonNov 20, 2018
  10. Stefan XenosNov 20, 2018
  11. Jonathan NiederNov 20, 2018
  12. Stefan XenosNov 20, 2018
  13. Jonathan NiederNov 21, 2018
  14. Stefan XenosNov 21, 2018
  15. Derrick StoleeNov 16, 2018
  16. Stefan XenosNov 17, 2018
  17. Duy NguyenNov 17, 2018
  18. Stefan XenosNov 18, 2018
  19. Stefan XenosNov 18, 2018
  20. Junio C HamanoNov 18, 2018
  21. Junio C HamanoNov 17, 2018
  22. Stefan XenosNov 19, 2018
  23. Junio C HamanoNov 19, 2018
  24. Stefan XenosNov 19, 2018
  25. Junio C HamanoNov 19, 2018
  26. Junio C HamanoNov 19, 2018
  27. Stefan XenosNov 19, 2018
  28. Jonathan NiederNov 19, 2018
  29. Junio C HamanoNov 20, 2018
  30. Stefan XenosNov 20, 2018
  31. Phillip WoodNov 20, 2018
  32. Phillip WoodNov 20, 2018
  33. Stefan XenosNov 20, 2018
  34. technical doc: add a design doc for the evolve commandPhillip Wood, Jan 15, 2019
  35. Phillip WoodNov 20, 2018
  36. Stefan XenosNov 20, 2018
  37. Phillip WoodNov 21, 2018

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.