If you want to undo a commit alternatively you can right click the commit and select Backout instead which will create a new commit that un-does the changes without modifying history. See changeset evolution on how this might not be such a problem in the future. So in general it is recommended not to modify history that has become public unless you know it’ll have no impact. It can also cause issues with automated test build systems that keeps the repository and just updates to the latest revision between builds. This might be easy to communicate if you’re working within a small team but becomes much harder to communicate if it’s a large team or an open source project online. This is something every developer has to do if they’ve pulled down the original commit. If you have local changes not yet pushed like in this example you would first have to move them over to the new commit using rebase before stripping the obsolete commits. To fix you would have to strip the obsolete commit.
#Tortoisehg upgrade update
So because the “Add workspace to app” commit was modified it now has a different hash (including all descendant commits since they’re modified too to update the parent hash reference since it’s changed), so it will appear as a different commit in the commit history alongside the original commit. The reason this happens is because commits are identified by their hash number (see identifying commits for more details). If another developer were to modify the “Add workspace to app” commit and you pulled down that change, this is what it would look like on your local repository: The risk with modifying history that you have pushed is if someone else has already pulled the commits down that you plan to modify. Firstly there is no risk to modifying history on commits that you have not pushed.
0 kommentar(er)
