The pieces of Git that are at odds with your desires are these:
Git commits are universally unique. Each commit has a unique hash ID, different from that of every other commit.
A Git repository is, primarily, a collection of commits, which may be shared with other repositories; if two repositories have commits that have the same hash ID, those are literally the same commits.1
A repository also has branch names: these names are not necessarily shared with any other repository. Each branch name holds one (1) hash ID. These serve to find some particular commit. Git calls these the tip commits of the branches. By definition, such a commit is the last commit in some chain of commits.
History, in a Git repository, is the commits in the repository. This comes about because one of the unalterable components in each commit is the raw hash ID of some earlier commit or commits.
What this means for you is that when you obtain commits from origin, those commits are inviolable and are history; their place in history is wherever they are in the chain that ends at some commit found by some name. Let's say, for concreteness, that you've obtained a commit whose hash ID is a123456 (actual hash IDs are larger and random-looking but this will serve here).
Any repository that has commit a123456 therefore has all the history that leads up to a123456.2 If you send commit a123456 to any other repository, it's your responsibility to send all the commits leading up to it, as well.3 That's why you end up sending the entire history to your remote named clean.
What this means for you is that if you want to have a different history in the repository you're calling clean, you must make a different set of commits. These commits, being different, are different history. There's a flaw in this ointment, which is that because these histories are unrelated, management of this new set of commits becomes very painful. You can do it, it's just that Git won't be terribly helpful. (You'll probably want to set up some naming scheme that keeps track of which commits you have already copied, and hence which ones you'll need to copy into clean as different commits. Once they're copied, you will update these "copy-tracking names", whatever you end up calling them, perhaps refs/copied/name to go with refs/heads/name.)
1This is why two commits that are different, but have the same hash ID, are verboten in a repository. I like to call such commits doppelgängers, with the evil connotation. Git will refuse to add one, modulo any bugs. See also How does the newly found SHA-1 collision affect Git?
2As a soft kind of exception, a shallow clone has some of the history leading up to here, with a cut-off "graft point" at which the repository just sort of shrugs its shoulders and says: I know the commit that comes before this has hash ID H but I have been told not to get H so I don't have it. But any repository that does have the commit with hash ID H has the one that has that place in history, so it's the same history, it's just not viewable from here.
3This rule is not removed for a shallow clone that is sending commits: if the sender wants the history and the sending-clone doesn't have it, the sending-clone can't complete this push. However, when the sender says I'll give you commit a123456 it's possible for the receiver to say ok, I'll take that one, I already have all its parents so no need to send any more history. So you can push from a shallow clone, as long as the clone you're pushing to already has the right history.
