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

[skillzero@gmail.com]

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?