Takashi Iwai wrote: > > At Thu, 23 Dec 2010 20:28:27 +0900, > Kukjin Kim wrote: > > > > Takashi Iwai wrote: > > > > > > > (snip) > > > > > > > > Anyway I need above commits from sound-2.6.git in my tree... > > > > > > so how method is better to me instead of cherry-pick it? > > > > > > > > > > You can merge topic/asoc branch of sound git tree. > > > > > This brach contains the all necessary commits for ASoC and is almost > > > > > never rebased. > > > > > > > > Hi, > > > > > > > > But I can't merge it because there is no 'topic/asoc' branch in > > > > sound-2.6.git. > > > > (git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound-2.6.git) > > > > > > > > Is there another repository? > > > > > > OK, Mark's tree doesn't contain. But you can merge for-2.6.38 tree there. > > > > > > The main sound git tree is found in > > > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git > > > > > Aha~ :-) > > > > > > And should I merge it in my tree even though don't need all of ASoC > > commits > > > > :-( ? > > > > > > In general yes because this is the tree to be merged to 2.6.38. > > > > > Yeah, I know it. > > > > > > I'm not sure how many commits are in there... > > > > > > You can keep two branches. One contains only your fixes, and another > > > is the merged branch from yours and from sound git tree. Expose the > > > latter merged tree for linux-next. > > > > > Yeah...however, firstly, my tree will be sent to rmk during 38 merge window, > > if I merge from sound git, for avoiding build error I should send all > > including them not only my patches. I think there is no need to rmk...hmm > > > > So I did 'cherry-pick' only needed 2 commits in my tree. > > And that caused problems :) > Yup...you're right. As I said, I couldn't suitable some branch for me. > > > There are many other ways to manage such things, but the above has > > > worked for me well, at least. > > > > Yeah I think so...but is there another better way in this case? Hehehe... > > Well, ideally, create a separate branch containing these cross-tree > commits based on vanilla. Then pull this branch to both arm (or your) > and sound trees. In that way, both trees share the same commits in > the least amount. > Yeah... > 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? Or sound maintainer should rebase his tree so that can make some branch which can support to avoid build error for me? ...Or because Stephen already informed about that so you or Linus can care just current tree during merge window? Which one is better to us? Or another method? Please let me know. Thanks and Merry Christmas everyone :-) Best regards, Kgene. -- Kukjin Kim <kgene.kim@xxxxxxxxxxx>, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- 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
