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

Re: Best practices for updating old repos

From
Stefan Beller <sbeller@google.com>
Date
Jun 16, 2017, 04:22 UTC
Message-ID
<CAGZ79kZMCz9g7PW6km3gQJU5qipw27jvkVDXD64MUNKJykYZOw@mail.gmail.com>
In-Reply-To
<59432BCC.2040901@eagerm.com>
On Thu, Jun 15, 2017 at 5:52 PM, Michael Eager <eager@eagerm.com> wrote:
Show 8 quoted lines
> One other variant of the rebase approach I've thought of is to do
> this incrementally, rebasing the old repo against an upstream commit
> a short time after the old repo was forked, fixing any conflicts,
> rebuilding and fixing build failures.  Then repeat, with a bit
> newer commit.  Then repeat, until I get to the top.  This sounds
> tedious, but some of it can be automated.  It also might result in
> my making the changes compatible with upstream code which was later
> abandoned or significantly changed.
This sounds like

https://github.com/mhagger/git-imerge https://www.youtube.com/watch?v=FMZ2_-Ny_zc

Previous: Michael EagerNext: Michael Eager
Message 2 of 5 in “Best practices for updating old repos”
  1. Michael EagerJun 16, 2017
  2. Stefan BellerJun 16, 2017
  3. Michael EagerJun 16, 2017
  4. Michael EagerJun 16, 2017
  5. Fwd: Best practices for updating old reposMichael O'Cleirigh, Jun 16, 2017

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.