2

My code depends on files provided by an existing repository. As each file requires some work, I want to bring the files in as they become supported, rather than just adding all files at once. I would also like to track from and commit changes to upstream for the imported files.

After some reading git subtree split seems promising and I followed the directions in

Git Subtree only one file or directory

with some modifications

git remote add project _URL_
git fetch project

then

git branch project_master project/master
git checkout project_master

then

git subtree split --squash --prefix=path_of_interest_in_project -b temp_branch

then

git checkout master
git subtree merge --prefix=directory_destination_path temp_branch

What happens is that git subtree merge seems to ignore the prefix flag and checks out the content of path_of_interest_in_project in the projects root folder. No squashing seems to be performed as the whole history of project/master is imported.

Is this the correct behavior or a bug in Git? Are there better solutions to achieve what I want?

Community
  • 1
  • 1
prinsen
  • 748
  • 6
  • 16

1 Answers1

1

I'm seeing something like what you describe, but it's not the subtree merge that is placing the subproject files in your project root, it's happens when you do a harmless old git pull with no specs.

The git remote add you did now thinks that the subproject is a valid upstream peer, and is pulling from it. Resulting in the unexpected stuff landing here.

My current work-around is to ensure I ONLY git pull from 'origin' from now on, but there is probably a setting in the tracking configs that would restore expected behaviour. I'm trying to find it...

dman
  • 1,089
  • 13
  • 9
  • After finding that almost nobody else had ever had this problem - I narrowed it down to the fact that I have `autosetuprebase = always` as a global default in my ~/.gitconfig . Removing `rebase = true` from my .git/config stops this problem from happening. Quite a gotcha – dman May 13 '15 at 04:16