clone into existing subdir

[brianjmurrell]

How can I force git subrepo to clone into a pre-existing dir where the result should be the combination of the dir's existing content and the content of the repo I am trying to subrepo into the existing dir?

Clearly I could git mv the existing dir contents out of the way, then git subrepo clone then git mv the contents back into the subrepo'd dir, but that leaves a mess in the history and I can't even squash those once I have done it because then I mess up git subrepos githash references.

[brianjmurrell]

Or, rather, I could squash them if I could fix up the metadata references. But I have tried to do this in the past and failed, but of course only discovered I'd messed it up some time down the road when a git subrepo pull needed doing and then I have to just throw away the subrepo and re-clone.

So if one is trying to squash a git subrepo clone commit into it's parent, is there anything more that needs doing than updating $subdir/.gitrepo to point the parent attribute at it's parent's parent?

[brianjmurrell]

Hrm. Maybe I was successful this time. I did just update the parent attribute to the parent's parent during my squash and after the squash was all done:

$ git subrepo pull include
Subrepo 'include' is up to date.

Seems to indicate that things are still working, yes?

Still, this was a long way around simply being able to clone a repo into an existing dir.

[grimmySwe]

@brianjmurrell so your use case is that you want to clone a repo into a repo that already contain files? Is that directory part of a repo, its own subrepo or what?

clone operation is and should be similar to regular git, it will clone an exact copy of the repo into a location.

The main problem with this is that there is no common ground on how to determine changes. You can of course first create a local subrepo from your local data, then try to pull in changes from your other subrepo. But it might cause some problems as you don't have a common ancestor so it's hard to know what is right.

There is a #328 where I have tested some new feature our adding some more information in the .gitrepo file to enable you to pick things from different places. It might be something for you to look into?

[brianjmurrell]

@grimmySwe The directory I want to clone into is just a directory that already exists in the project I am doing the subrepo clone into.

So I have this git project cloned at foo/ and I want to git subrepo ... include to put the subrepo at foo/include/. All pretty normal so far, but in this case, foo/include/ already exists with some files (that don't overlap the project I am subrepo'ing at foo/include/.

I ended up achieving the goal by doing some git mvs of the content that was already in foo/include/ outside of foo/include/ and then doing my git subrepo clone ... include and then git mving the previously moved content back into foo/include/ for that "plus local changes" use-case of git subrepo.

That made a bit of a mess of the history though, as I am sure you could imagine, that would have been preferable to not have had to make.

[grimmySwe]

@brianjmurrell When you say that you have files that don't overlap, are they still files that you want to include into the subrepo? Will you push so others can access them? If not, I think you will create extra work for yourself as they will be handled as special cases each time and you can't actuall push back changes to the other files without adding these as well.

If they should be included, I think that the #328 workflow should be able to handle this. So that you first create a local subrepo and then you pull in the changes from a remote. Not fully confident that it works completely but I think that it should be the target workflow for this case.

[grimmySwe]

Closing this issue, see #328 for possible solutions to this.