{"thread":{"id":"42322","subject":"Subtree split unsquashes everything","startedAt":"2016-05-14T16:53:00Z","lastAt":"2016-05-22T00:30:13Z","messageCount":3,"participants":["Joseph Musser","David A. Greene"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"286538","messageId":"CAKRjdd7Czj2iTKdwVCmz4x9fDNKCPZtLi=UjgHOsSPuYL_yLXg@mail.gmail.com","threadId":"42322","inReplyTo":null,"subject":"Subtree split unsquashes everything","fromName":"Joseph Musser","fromEmail":"me@jnm2.com","sentAt":"2016-05-14T16:53:00Z","receivedAt":"2016-05-14T16:53:00Z","isPatch":false,"sender":{"key":"me@jnm2.com","avatar":"https://gravatar.com/avatar/82a7d3ba27eefb8c496774b34d193877cb5a3eec5374a07a27506d32c9ba9d89?d=mp&s=160"},"body":"Hello! I was directed to ask here; I hope I am respecting your format.\n\nI have a repo with a subtree. I squashed every merge with the subtree\nremote to keep the history manageable. Now down the road after a bunch\nof merges, I need to split my repo’s master branch into two new\nbranches and move the subtree from `/subdir/subdir/` to `/`.\n(`/subdir/subdir/user/mycode/` contains code from my repo.)\n\nI ran `git subtree split -P=subdir/subdir/ -b newbranch` and the\noutcome seems to be perfect except that each squash merge has turned\ninto a full merge, bringing along all history from the other repo. Why\ndoes it do this and how can I preserve my repo history, including only\nsquashes from the subtree remote repo like it is today?\n\nI initially asked at http://stackoverflow.com/q/36957809\n\nThank you.\n"},{"id":"287172","messageId":"87a8jjouvo.fsf@waller.obbligato.org","threadId":"42322","inReplyTo":"CAKRjdd7Czj2iTKdwVCmz4x9fDNKCPZtLi=UjgHOsSPuYL_yLXg@mail.gmail.com","subject":"Re: Subtree split unsquashes everything","fromName":"David A. Greene","fromEmail":"greened@obbligato.org","sentAt":"2016-05-21T23:26:35Z","receivedAt":"2016-05-21T23:26:35Z","isPatch":false,"sender":{"key":"greened@obbligato.org","avatar":"https://avatars.githubusercontent.com/u/5291869?v=4"},"body":"Joseph Musser <me@jnm2.com> writes:\n\n> I ran `git subtree split -P=subdir/subdir/ -b newbranch` and the\n> outcome seems to be perfect except that each squash merge has turned\n> into a full merge, bringing along all history from the other repo. Why\n> does it do this and how can I preserve my repo history, including only\n> squashes from the subtree remote repo like it is today?\n\nThe only thing that --squash does on an add/merge/pull is a read-tree of\nthe fetched commit into a new commit in the host repository which is\nthen merged in to the host repository's branch.  It also annotates the\nhash of the original commit in the git-subtree-split metadata.\n\nAs the split code processes commits it records parents to link up the\nhistory to that in the subtree's original repository.  Crucially, the\ngit-subtree-split metadata of the commit message git-subtree creates for\nsquashes lists the original commit ID of the squashd commit.  That lets\ngit-subtree hook up split commits back to the original project history.\nI believe that's why the split branch is showing the full history.  It's\nbaked into the split algorithm.\n\nPresumably you split the subdirectory from the same working repository\nin which you added the subtree commits in the first place.  Thus the\nhistory of the original project is all there (it was fetched when the\nsubtree was added/merged).  I have not tested this, but I wonder what\nwould happen if you either deleted that history from the host repository\nor you cloned the host repository to a new place and tried the split\nthere.  The original hisory wouldn't be there and git-subtree would not\nhave it to hook up to.\n\nI have mentioned before that I'm working on a complete overhaul of the\nsplit code.  Since git-subtree split it typically used to send commits\nback to the original subtree repository, I never imagined that someone\nwould *not* want to get the original history back.  If the squash were\nnot reversed we would not be able to merge the history back in to the\noriginal repository.  If keeping squashes is truly desired I will have\nto think about how to do that, likely as a non-default option to split\nor even an entirely different command.\n\n                      -David\n"},{"id":"287176","messageId":"CAKRjdd6JKxp3B1EaiyGUaHfHYRh_N2a8gGEW7k4K-Ng0FHR3ww@mail.gmail.com","threadId":"42322","inReplyTo":"87a8jjouvo.fsf@waller.obbligato.org","subject":"Re: Subtree split unsquashes everything","fromName":"Joseph Musser","fromEmail":"me@jnm2.com","sentAt":"2016-05-22T00:30:13Z","receivedAt":"2016-05-22T00:30:13Z","isPatch":false,"sender":{"key":"me@jnm2.com","avatar":"https://gravatar.com/avatar/82a7d3ba27eefb8c496774b34d193877cb5a3eec5374a07a27506d32c9ba9d89?d=mp&s=160"},"body":"Thanks for the response.\n\nI began to wonder if indeed I was using the correct paradigm, since\nthe split operation would leave the subtree prefix as `/` which is an\nimpossible prefix when creating a subtree. Attempting to add a new\nsubtree with prefix `/` results in an error because the prefix\ndirectory is not empty (it contains `.git`).\n\nLong story short, I realized I probably had to start over without\nusing subtree at all and manually rebase and remerge. I discovered\nthat now that I'm not using subtree, I can no longer squash merge. It\nworks for the first merge but subsequent squashes do not remember what\nthe previous squash's parent commit was from the other repo. (The\nsubtree subsequent squash merge experience was perfect.) I decided to\nbe okay with that and give up the idea of squashes; I can use `git log\n--author=jnm2` so that I can actually read my history, and in the\nunlikely scenario that I can't access the other repo at least I'll\nhave full history.\n\nThe only thing I dislike is that I'm giving up the concept of that\nseparation between two repos in the same working tree- that some files\nbelong to one repo and some to the other. That's a cool paradigm.\nSince my access to the other repo is read only, I suppose that doesn't\nmatter. I can't use subtree because the prefix would be `/`, and I\ncan't use submodule because my repo needs to track my changes inside\nthe prefix as part of my repo.\n\n> I have not tested this, but I wonder what would happen if you either deleted that history from the host repository or you cloned the host repository to a new place and tried the split there.\n\nI tried that in the course of my tests earlier; if I remember\ncorrectly, I lost the squash merge history. Git log showed only the\nparents from my repo. I couldn't do a new squash merge because it lost\ntrack of the most recent squash's parent commit in the other repo.\n\n> I never imagined that someone would *not* want to get the original history back\n\nIt's possible that what I was trying to do made no sense in the first\nplace. It's likely that I'm missing something since I'm new to these\nconcepts. I feel like I've settled for a less clean solution but I\ncan't put my finger on it. I'm willing to try a different\nconfiguration.\n\nJoseph\n"}]}