-
-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
History of renamed files is not followed by split #33
Comments
Today I ran into the same issue for the first time, adopting what used to be a monorepo. Any new recent thoughts available on this matter? |
Well, the splitter is keeping only the Keeping files outside the root of the subtree in order to show a full history will be an issue for multiple reasons:
|
When a move into a splitting prefix occurs, one could at that commit:
This would enable files to be moved into the split subtree (with their full history) after the split's initial creation without rewriting the split's history. It does however raise (at least) one problem: where source commits that affected such new file also affected files already within the target split, they will not be unified into a single commit but will instead exist as distinct commits with identical metadata (author, timestamp, commit message etc); this may be acceptable in some cases, and rewriting the history to avoid it may be acceptable in other cases. |
Given that file moves don't exist in Git (they are detected based on similarity of files when generating a diff), I think this would increase the cost of the splitting a lot (the current splitter does not actually care about the diff AFAICT) |
I can't speak to the cost, perhaps it's too great (albeit a feature that could be enabled only when desired, e.g. via command-line switch)... but surely only commits that involve the creation of a new file within the prefix need be inspected for file deletions of similar size outside of the prefix before any similarity detection need be performed? |
We are restructuring our code into multipackage repository, so we move around a lots of files eg. from
/app/templates/foo.hbs
->/packages/foo-package/app/templates/foo.hbs
We want to use downstream readonly repos with the subpackages.
The problem we have encountered is that renames are not followed by
splitsh-lite
, so our history in downstream repos is limited only to commits after a rename.Reproduction script:
Script output:
Inspecting history of created branches shows that after rename history is not followed:
@fabpot Is there a way to preserve history (ie. follow renames)?
The text was updated successfully, but these errors were encountered: