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 20, 2018, 20:24 UTC
Message-ID
<CAPL8ZiukW+mkYBpk-qSmpy3o8u0-mVtcytKLHMz8wpkDd+mRKQ@mail.gmail.com>
In-Reply-To
<d77c4aa6-be5e-a6fe-1d43-6cfa28161ae1@talktalk.net>
> If a merge has been cherry-picked we cannot update it as we don't record
> which parent was used for the pick, however it is probably not a problem
> in practice - I think it is unusual to amend merges.

I've read and reread that sentence several times and don't fully understand it. Could you elaborate?

It sounds scary, though. With the evolve command, amending merges will need to be supported. If you create a merge and then amend one of its parent commits, the evolve command will need to rebase the merge and point one or both parents to the replacement instead.

  - Stefan
On Tue, Nov 20, 2018 at 5:03 AM Phillip Wood <phillip.wood@talktalk.net> wrote:
Show 24 quoted lines
>
> On 15/11/2018 00:55, sxenos@google.com wrote:
> > From: Stefan Xenos <sxenos@google.com>
> >
> > +Obsolescence across cherry-picks
> > +--------------------------------
> > +By default the evolve command will treat cherry-picks and squash merges as being
> > +completely separate from the original. Further amendments to the original commit
> > +will have no effect on the cherry-picked copy. However, this behavior may not be
> > +desirable in all circumstances.
> > +
> > +The evolve command may at some point support an option to look for cases where
> > +the source of a cherry-pick or squash merge has itself been amended, and
> > +automatically apply that same change to the cherry-picked copy. In such cases,
> > +it would traverse origin edges rather than ignoring them, and would treat a
> > +commit with origin edges as being obsolete if any of its origins were obsolete.
>
> If a merge has been cherry-picked we cannot update it as we don't record
> which parent was used for the pick, however it is probably not a problem
> in practice - I think it is unusual to amend merges.
>
> Best Wishes
>
> Phillip
Previous: Phillip WoodNext: Phillip Wood
Message 36 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.