Maintaining a fork workflows

Christos Trochalakis· Feb 12, 2010, 09:23 UTC · lore

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· Feb 12, 2010, 12:37 UTC · re: Christos Trochalakis · lore

Re: Maintaining a fork workflows

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