Re: git merge and cherry-pick and duplicated commits?

I guess maybe a better question is how do people normally handle situations like mine where I did some work on branch X and I later realize I need only a portion of that work on branch Y? I'm not sure how I can change my workflow to completely eliminate these situations. For example, I often start a branch to add a new feature and I end up fixing bug A on that branch. Then other people on my team decide they need the fix for bug A immediately and can't wait for me to finish my feature branch and do a full merge.

Is there some way I can change my workflow such that I can fix bug A (maybe on a separate branch?) and somehow apply it to both both branches in a way that won't result in duplicate commits?

Does this kind of thing ever happen with the Linux kernel or git itself: somebody does a fix as part of their topic branch and the Linux kernel or git master wants that particular fix now, but is not ready for the full topic branch? Would they just suggest the fix be separated into its own topic branch and that merged? If so, how would that new topic branch merge into the original topic branch without resulting in a duplicate commit when it's later merged into master?