git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Subtree split unsquashes everything

From
David A. Greene <greened@obbligato.org>
Date
May 21, 2016, 23:26 UTC
Message-ID
<87a8jjouvo.fsf@waller.obbligato.org>
In-Reply-To
<CAKRjdd7Czj2iTKdwVCmz4x9fDNKCPZtLi=UjgHOsSPuYL_yLXg@mail.gmail.com>
Joseph Musser <me@jnm2.com> writes:
Show 5 quoted lines
> I ran `git subtree split -P=subdir/subdir/ -b newbranch` and the
> outcome seems to be perfect except that each squash merge has turned
> into a full merge, bringing along all history from the other repo. Why
> does it do this and how can I preserve my repo history, including only
> squashes from the subtree remote repo like it is today?

The only thing that --squash does on an add/merge/pull is a read-tree of the fetched commit into a new commit in the host repository which is then merged in to the host repository's branch. It also annotates the hash of the original commit in the git-subtree-split metadata.

As the split code processes commits it records parents to link up the history to that in the subtree's original repository. Crucially, the git-subtree-split metadata of the commit message git-subtree creates for squashes lists the original commit ID of the squashd commit. That lets git-subtree hook up split commits back to the original project history. I believe that's why the split branch is showing the full history. It's baked into the split algorithm.

Presumably you split the subdirectory from the same working repository in which you added the subtree commits in the first place. Thus the history of the original project is all there (it was fetched when the subtree was added/merged). 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. The original hisory wouldn't be there and git-subtree would not have it to hook up to.

I have mentioned before that I'm working on a complete overhaul of the split code. Since git-subtree split it typically used to send commits back to the original subtree repository, I never imagined that someone would *not* want to get the original history back. If the squash were not reversed we would not be able to merge the history back in to the original repository. If keeping squashes is truly desired I will have to think about how to do that, likely as a non-default option to split or even an entirely different command.

                      -David
Previous: Joseph MusserNext: Joseph Musser
Message 2 of 3 in “Subtree split unsquashes everything”
  1. Joseph MusserMay 14, 2016
  2. David A. GreeneMay 21, 2016
  3. Joseph MusserMay 22, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.