I don't see B in your picture, so I may not be answering the question you wanted to ask, or you perhaps asked something other than the question you wanted to ask. Having said that, I think you are asking two more-or-less independent questions.
Whether you interact with your upstream by sending patches, asking them to pull, or directly pushing into them, from your problem description, it is clear that you _only_ want to give change contained in A' and B'. So there is no room for "how do I" involved in it.
(1) First check out a pristine copy of your upstream, and cherry-pick A'
and B' $ git checkout upstream ;# or whatever
$ git cherry-pick A'
$ git cherry-pick B' (2-a) If you are sending patches to interact with your upstream, then
format-patch the two [*1*] $ git format-patch -2
and send them out.
(2-b) If you are asking for them to pull, publish that to your public
repository and ask. Perhaps... $ git push $publicURL HEAD:for-upstream
$ mail integrator@upstream.com
Subject: please pull Please find my two changes at
$publicURL for-upstream (2-c) If you can push, you push it to whichever branch the others are
expecting you to push to. Perhaps... $ git push $upstreamURL HEAD:$branch
Now, how to deal with the duplicate copies A' and B' in your private
history is your problem, and it is largely independent from the above.
If your branch W is private and you haven't published, then you would want to drop the now-obsolete two commits that do not belong to what you wanted to achieve in that branch by running "rebase -i", perhaps...
$ git rebase -i A'^
... delete lines that correspond to A' and B' and save ...
If your branch W has been published (iow, other people have seen the commits on it), then you shouldn't be doing rebase. When you merge upstream to W (but why would you do that in the first place? You shouldn't be working directly on a branch that you merge random changes from other people), you _will_ end up having A and A' (and B and B') as duplicates in your history. You'll need to live with it.
A good news is that git was designed for the Linux kernel community where patch duplication is the norm, not exception. Over there, it is not uncommon for a subsystem maintainer to pick up a patch from the mailing list that falls within his area, while the maintainer at the higher level than the subsystem maintainer picks up the same patch (perhaps because it trivially fixes a rather urgent issue) and then later ends up merging with the subsystem maintainer. When this happens, git notices that the two sides made exactly the same change and resolves it as a non-conflicting event when able (and it often is).
[Footnote]
*1* cherry-pick may not seem useful in this case, but it is a courtesy to your upstream to give them a clean patch; cherry-picking and adjusting for potential conflicts on top of the pristine upstream before running format-patch will ensure this.
Jeenu V