0

I'm currently working with a repository that has recently been broken up for the sake of close-sourcing - modules have been moved to their own repository away from the 'main' one.

panel/
    file.a
    file.b
    module1/ [untracked by panel repository, instead tracked in own repository now]
        templates/
            base.html
            ...
        views.py

However, there is still work that was committed before this break-up, when the module1 repository was still part of panel. My issue is working with the commits from before and after this break-up - I'm currently trying to cherry-pick a commit with changes to files in both panel and module1, a commit that was created when both repositories were part of panel. (No directory structure has changed, only git's view of the repositories)

When I cherry pick while in the main repository's directory:

nasonfish@nasonfish ~/P/P/p/panel2> git cherry-pick 8b7316d1ebff49e95a7971f88e669f50d9cbbf86
error: refusing to lose untracked file at 'panel/module1/views.py'
error: refusing to lose untracked file at 'panel/module1/templates/module1/view-hdr.html'
error: refusing to lose untracked file at 'panel/module1/templates/module1/view-base.html'
error: refusing to lose untracked file at 'panel/module1/templates/module1/base.html'
error: could not apply 8b7316d... mybranch: This is my commit
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'

I can see that I'm not looking to remove or add the files in the repository to the main repository because that just undoes the separation and combines the repositories - but I'm trying to make the cherry-pick apply that commit to the files in both the base and child repository without merging the two. So, is there a way to force git to act like the files in a separate nested repository are part of the main repository in some way that allows cherry-picking commits from before the repositories were separated?

nasonfish
  • 295
  • 1
  • 3
  • 13

1 Answers1

0

After some thought about how I could apply a certain commit to the files without regard to their repository, my eyes turned to generating patches to apply.

I first discovered how to create a patch from a commit hash:

git format-patch -1 8b7316d1ebff49e95a7971f88e669f50d9cbbf86

I then applied my patch using git apply (since I can't say for certain the patch will merge perfectly with what I have, I applied the --reject switch in order to merge what I can and dump out what doesn't work for manual merging):

git apply 0001-permissions-Add-a-new-user-permissions-system-that-c.patch --reject

I then searched my repositories for .rej files that contain patches I have to merge manually, and used those files to apply changes to the files they were intended to be merged into.

After that, I know I have the changes applied spanning across my repositories, and I can simply change directories into each repository and use git commit to indicate what I have merged.

Community
  • 1
  • 1
nasonfish
  • 295
  • 1
  • 3
  • 13