On Fri, Dec 24, 2010 at 10:32:33AM +0900, Kukjin Kim wrote:
> Takashi Iwai wrote:
> > I basically don't like to rebase and the commits have been already in
> > sound tree, but if this is the only way and Russell prefers this, it
> > can be a possible option.
> >
> I agree with you...now, rebase stuff is unnecessary load to you.
>
> Ok...firstly, need to ask to Russell.
> (Added Russell in To)
>
> Hi Russell,
>
> Sorry for bothering...
> If possible, please read this thread :-)
>
> So...
>
> May/Should I merge sound tree for avoiding build error and conflict between
> each other for 37 merge window instead of cherry-pick?
IMHO it is never appropriate to cherry pick commits from someone elses
tree into your own tree as it creates duplicates in the history.
What would be better is to talk to the person who owns the tree with
the commits you're interested in, and see about merging the minimal
set of commits you need into your own tree. They may tell you the
name of a branch for you to merge into your tree (preferred), or more
obscurely tell you a commit id in their tree.
Now there are two options:
- If you know the branch you need, you can then either pull that branch
into your tree, and commit the dependent patches on top of that.
- If you only have a commit ID in the remote tree, you can fetch their
tree first, use gitk to visualize the history and check you have it,
and then do:
git merge --no-commit <commitid>
in your tree. Then commit the result with your own commit message
explaining what's going on.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
