I had some code changes that I accidentally pushed to the team repo and as such I created extra heads. Usually I keep those changes in my own repo but I just forgot to refer to the changeset to push and ended up with extra heads. To solve this problem I used the tip in How to merge to get rid of head with Mercurial command line, like I can do with TortoiseHg? Works great to me, in fact I am quite happy with the fact that this way my changes are not lost at all and that team members don't have to strip any files in their repo. As matter of fact even though this head is not used, I might want to refer to it in the future and do take some of those changes.
Now after I did this change I got a reaction from a colleque who is our mercurial expert as follows : [begin quote] The main issue now will be that everyone also in MS will have have these changesets, will see merge ‘arrows’, will see this in history despite that it is not included. Also the ‘merge’ commit does not mention at all that this is a dummy merge. So in case you add other heads that later on have to be dummy merged, please clearly comment this in the next merge commits to clarify this is the case.
Also the adding and removing and changing files, can become a problem now. I am not sure if this will be the case now due to the dummy merge, it might optimize that these files were not impacted, this will have to be tested. [end quote]
my reaction is that a dummy merge is easily seen, if you select it in TortoiseHg, you just don't see any changes. A commit message 'dummy merge' is probably a good idea. So that point is taken. The fact that my changes are seen by everybody, is hardly a problem for me, on the contrary this way they are kept and are a future reference. I don't see the problem here.
But the last bullet in bold about the adding removing and changing files ? Can this really be a problem in mercurial? Is this not the essence of using a versioning system in the first place ? What should I test, like he seems to suggest ? Is his comment correct ?
