pull into dirty working tree

We have some CVS users who complain that they cannot do a pull
into a dirty working tree, as they could under CVS.  Here is
their scenario: they make a few changes to their code and want
to test it out; someone else pushes changes to the central repo
that they then want to add to their working tree to test also;
they then want to pull in these changes and test everything, as
if they had done 'mv stuff stuff-; git pull; mv stuff- stuff'.

They would like an option (perhaps a config option) to do a "dirty
pull".

The git-merge documentation states:

  You may have local modifications in the working tree files. In other
  words, git-diff is allowed to report changes. However, the merge uses
  your working tree as the working area, and in order to prevent the
  merge operation from losing such changes, it makes sure that they do
  not interfere with the merge. Those complex tables in read-tree
  documentation define what it means for a path to "interfere with the
  merge". And if your local modifications interfere with the merge,
  again, it stops before touching anything.

But my colleagues are still wondering: why can't git just do it as
CVS does?

I know there are workarounds: I myself documented a set of commands
to "put things on a shelf", but they still are whining.

I need a convincing argument: not a technical one, but one that is
practical (e.g. where CVS would do harm that git is preventing).

So, any explanation that I can give them why we can't have a 'git pull
--dirty' that moves things out of the way, then does the merge, then
moves thing back, aside from that it is stupid?


Bill