Three issues to do with merging...

[Gerard Murphy]

Hi - I documented this post before in the user voice site, but I think it makes more sense to place it here...

 

This is feedback based on three separate issues I've seen on different occasions when merging:

 

 

1. If a pending merge results in no actual file changes, it doesn't seem possible to back out of the merge if it's not the desired result: the merge link can't be undone without at least one change to a file in the pending merge.

I got into this situation doing a sophisticated merge; a directory in the source branch had been deleted, but a new file has been added on the source branch in that directory that I wanted to merge over into a different location on the target branch.

I chose the merge conflict resolution of preserving the delete for the directory (I had forgotten about the new file) - once I realized my mistake, I couldn't back out of the pending merge.

I tried forcing an undo by shelving and undoing via the shelve - this led to an internal of-by-one indexing error in Plastic. 
I also tried switching my workspace to another changeset, hoping that might break the merge link - but Plastic moves the merge link to the new changeset (which is actually the right thing to do). 
I also tried committing the pending merge to a new branch with the intention of deleting the branch and thus losing the merge changeset - but this was blocked by Plastic.

In the end I had to destroy the workspace and start a new one - this wasn't that big a problem, as I had no changed files, but is inconvenient.

 

So it would be good to extend the undo functionality to remove a pending merge link in the absence of file or directory changes

.

This has bit me several times so far - my latest workaround is to just make a throwaway edit on a file and then undo everything, but having a direct undo would be much slicker.

 

2. I managed to make a poor commit when I made another merge, which went ahead automatically, but had to do some manual edits in the changeset to get my project to build properly - this was not the fault of the merge, simply a case of extra steps being necessary to get a correctly working result. Now, Plastic doesn't monitor externally-made changes in the workspace when one works in the Plastic GUI, so I didn't see some files that had changed due to reconfiguring the NuGet dependencies in my Visual Studio solution when fixing up the build before committing the final merge. When I finally committed, the GUI updated and showed me the additional changed files that should have been in the commit in the first place. The end result was a broken commit followed by a 'patch-up' commit. Not the end of the world, but messy.

 

I suggest adding an internal pre-commit check in Plastic that re-scans the workspace, popping-up a warning if new pending changes are detected that are not in the commit (or even if the files in the commit have changed from the deltas that Plastic thinks it had at the start of the commit). The workspace view would update before the pop-up, rather than wait until after the commit.

 

I know that continuous pro-active scanning of the workspace is not something you guys wish to consider, and that makes sense to me - this is just a one-off done as a built-in pre-commit hook.

 

3. Sometimes it's handy to reject changed files individually when doing a merge that has proceeded automatically without conflicts. At the moment I can't do this, because attempting to undo the changes on a single file makes Plastic want to delete the merge link. This makes sense 98% of the time, but would it be possible to tell Plastic when it has successfully merged but has not yet committed to simply throw away the changes on a merged file while still keeping the merge link?

 

This is an extreme edge case of when one performs a merge, but needs to 'massage' the resulting files in the pending merge state prior to committing.

 

I suggest adding a retrospective 'choose source or destination' option in the pending changes view when it is showing the uncommitted results of a completed successful merge - this would achieve the desired result but allow Plastic to keep the existing merge link.