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

Re: Maintaining a fork workflows

From
MPMichael Poole <mdpoole@troilus.org>
Date
Feb 12, 2010, 12:37 UTC
Message-ID
<87k4uid3zo.fsf@troilus.org>
In-Reply-To
<f7b87f7c1002120123t376f3f14ma3f3bcb21ae2836@mail.gmail.com>
Christos Trochalakis writes:
Show 11 quoted lines
> Hello, I have created a light fork of an upstream project and I am not
> quite sure which "syncing with upstream" workflow fits better.
>
> I can think of 3 solutions
> 1. the obvious one, merge the upstream changes on the forked branch
> and make the necessary modifications on the merge commit
> 2. Rebase upstream commits on top of the fork & make a commit with the
> necessary modifications
> 3. Cherrypick & modify upstream commits
>
> Which practice is considered better?

I would recommend #1 if you expect other people to base work on your tree, and #2 if you don't. #1 preserves both tree's histories, rather than occasionally rewriting your tree's history like #2 does. #3 at best hides the relationship between the upstream history and the cherry-picked commits, which is why it isn't a serious contender to me.

Michael Poole
Previous: Christos Trochalakis
Message 2 of 2 in “Maintaining a fork workflows”
  1. Christos TrochalakisFeb 12, 2010
  2. Michael PooleFeb 12, 2010

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.