Assuming I have already added a new remote "foo", and pulled a subtree, squashed, with branch master.
$ git remote add -f foo some-repo.git
$ git subtree add --prefix=foo --squash foo master
From the articles I have read (here, and here, etc), this appears to be the common way to switch branches. In this case, to branch "bar":
$ git rm -r foo
rm 'foo/file'.
...
$ git commit -m "Delete foo on branch 'master' to switch to branch 'bar'."
1350 files changed, 144703 deletions(-)
delete mode 100644 foo/file
...
$ git subtree add --prefix=foo --squash foo bar
git fetch foo master
From some-repo.git
* branch master -> FETCH_HEAD
Added dir 'foo'
But this feels dirty. Why not just use "git subtree pull" which already has a branch argument (no rm/commit/add)?
$ git subtree pull --prefix=foo --squash foo bar
From some-repo.git
* branch master -> FETCH_HEAD
Merge made by the 'recursive' strategy.
foo/file | 2 ++
... smaller changeset output ...
3 files changed, 41 insertions(+)
...
When I have tested both locally, I see no differences between the subtree dirs (./foo). Why is everyone recommending the way that adds more complex changesets and commits (removing and re-adding)? What am I missing, maybe some edge cases?
