* Maintaining a fork workflows
@ 2010-02-12 9:23 Christos Trochalakis
2010-02-12 12:37 ` Michael Poole
0 siblings, 1 reply; 2+ messages in thread
From: Christos Trochalakis @ 2010-02-12 9:23 UTC (permalink / raw)
To: git
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
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: Maintaining a fork workflows
2010-02-12 9:23 Maintaining a fork workflows Christos Trochalakis
@ 2010-02-12 12:37 ` Michael Poole
0 siblings, 0 replies; 2+ messages in thread
From: Michael Poole @ 2010-02-12 12:37 UTC (permalink / raw)
To: Christos Trochalakis; +Cc: git
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2010-02-12 12:37 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-02-12 9:23 Maintaining a fork workflows Christos Trochalakis
2010-02-12 12:37 ` Michael Poole
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.