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 - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
