![]() As a result, the parent of "v1.1.1build25" needs to be the new commit. Now a new commit has replaced "v1.1.1build24" and "darn, property list encoding". ![]() The parent or the base of "v1.1.1build25" was "v1.1.1build24". Git implements this squash by creating a new commit, whose parent is "Xcode 10.2, Swift 5" and whose changes are equivalent to those of "darn, property list encoding" and "v1.1.1build24". "darn, property list encoding" and "v1.1.1build24" are squashed as one commit. My question is: why did that happen, and what should I have done instead? It wasn't exactly a new "branch" (as my question title has it) but the existing commits up thru "v1.1.2build28" ended up on their own dead-end branch line, and master now had these new commits in it, duplicating those commits but without the tags and with today's date. I couldn't understand why, and it took me a lot of scurrying around to clean it up. There is no remote so I'm free to rewrite history and keep it clean and informative.īut when I did that, a whole bunch of new commits were created branching off from "Xcode 10.2, Swift 5" - copies of the existing chain of commits. So, in this situation, I asked SourceTree to do an interactive rebase on the children of the bottommost commit ("Xcode 10.2, Swift 5"), because I wanted to collapse the next two commits ("darn, property list encoding" and "v1.1.1build24") into a single commit. ![]() Here's a picture of the last part of my simple straightforward history (from SourceTree, time marches from bottom to top):
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |