# Maintaining a fork workflows 2 messages from 2010-02-12 to 2010-02-12. Participants: Christos Trochalakis, Michael Poole. Thread: https://gitlist.dev/t/22626 ## Christos Trochalakis, 2010-02-12 09:23 Subject: Maintaining a fork workflows Message-ID: URL: https://gitlist.dev/e/f7b87f7c1002120123t376f3f14ma3f3bcb21ae2836%40mail.gmail.com ``` 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? thanks, chris ``` ## Michael Poole, 2010-02-12 12:37 Subject: Re: Maintaining a fork workflows Message-ID: <87k4uid3zo.fsf@troilus.org> URL: https://gitlist.dev/e/87k4uid3zo.fsf%40troilus.org In-Reply-To: ``` Christos Trochalakis writes: > 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 ```