I am currently using git subtree in a project :

This is basically a set of cmake scripts that help writing convention
based (folder hierarchy, etc.) cmake builds.

My setup is that "master" has the set of scripts needed. and many
other branches ("test" and "tests/*" most notably) have tests projects
for these scripts. Travis run build of these to check if the build
setup works as expected.

The "test" branch has a hierarchy of dependent projects (ProjectA,
ProjectB, ProjectC) , all using the wkcmake scripts to build.

So I am using git-subtree to pull and push  "ProjectA/CMake"
ProjectB/Custom CMake" "ProjectC/CMake".

I had enough trouble with push to stop using it( merge not happening
as I thought it would ). Not sure if I am to blame or not for these...
Anyway now, after a commit into the test branch, I instead split the
CMake subtree to a new branch, and merge in manually back to master.
That seems to work okay so far.

However I realized that when I do :
 git subtree pull -P ProjectA/CMake g...@github.com:asmodehn/
wkcmake.git origin master
 git subtree pull -P "ProjectB/Custom CMake"
g...@github.com:asmodehn/wkcmake.git origin master
 git subtree pull -P ProjectC/CMake
g...@github.com:asmodehn/wkcmake.git origin master

I get only one merge commit into the "test" branch. All the other
subtree pull returns "Already up to date" even though the content of
the working directory in the prefix passed is NOT uptodate.

The possible behavior that I could understand would be :
- One subtree pull update all prefixes, with only one merge commit,
and the prefix doesnt really matter anymore ( could be problematic...
- Each subtree pull update the appropriate prefix with one merge commit each.

So I am curious : I this a scenario that subtree doesnot support ?
Am I using it wrong ?
Is it a current limitation/bug of subtree that is on the roadmap to be
addressed sometime in the future ?

Thanks a lot for the help.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to